RFC: Collections reform

This is a combined *conventions* and *library stabilization* RFC. The goal is to establish a set of naming and signature conventions for `std::collections`.

The major components of the RFC include:

* Removing most of the traits in `collections`.

* A general proposal for solving the "equiv" problem, as well as improving `MaybeOwned`.

* Patterns for overloading on by-need values and predicates.

* Initial, forwards-compatible steps toward `Iterable`.

* A coherent set of API conventions across the full variety of collections.

*A big thank-you to @Gankro, who helped collect API information and worked through an initial pass of some of the proposals here.*

[Rendered](https://github.com/aturon/rfcs/blob/collections-conventions/active/0000-collections-conventions.md)
This seems strange. According to the [multidispatch RFC](https://github.com/aturon/rfcs/blob/associated-items/active/0000-associated-items.md#coherence-implications), there must be ‘at most one applicable `impl`’ for any trait and its input types. But `|| -> T` unifies with `T`, so the `impl<T> ByNeed<T> for T` could apply to `|| -> T` as well. Am I misunderstanding the multidispatch RFC? Also, this seems like it would interact badly with types like `Option<|| -> int>`, even if coherence would let this through.

(Also, typo: there is an extra `)` after the multidispatch link.)