Refactor collections::List<T> to avoid using managed boxes

[brunoabinader]

After closing #12344, we should think about the best strategy for replacing usage of managed boxes inside List<T>. @alexcrichton, @bill-myers and @eddyb provided good hints on how we should implement List<T> internally (i.e. instead of using an enum, use a struct-based approach with 'head' and 'tail').

[brunoabinader]

My initial idea was to simply replace manage box with owned or even refcounted box. I have some prototypes ready however I'd require some help writing benchmark tests to verify. The idea that Cons and Nil as duplicates for the Option behavior is also correct, so it might be simple to just get rid of enum and go for a struct, Option-based approach.

[huonw]

Using Rc<...> seems like a good, preferable idea, because it allows for sharing tails.

(With owned boxes, the linked list becomes a plain owned stack, and std::vec_ng::Vec (or, ~[]) are better versions of these stacks on most dimensions: lower memory use, better cache locality, still have (amoritised) O(1) push/pop, O(1) indexing/length...)

[pongad]

Close since List has been removed?