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)
@alexcrichton Yes, the fact that the "default" interpretation is a moving iterator is perhaps a bit weird. On the other hand, moving is the default almost everywhere in Rust, and with this approach you get to use `&` and `&mut` to easily select other forms of iteration.

Unfortunately, it's a bit tricky to make `for` use by-ref iterators instead. The problem is that an iterator is `IntoIterator`, but it is *not* `Iterable` (or whatever we call the by-reference trait). Why? Because `IntoIterator` gives you an iterator that can be used only once, while `Iterable` allows you to ask for iterators repeatedly.

If `for` demanded an `Iterable`, then `for x in v.iter()` and `for x in v.iter_mut()` would cease to work -- we'd have to find some other approach. It might be doable, but offhand I don't see how.