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)
I do agree that it's hard to do a by ref iterator with a naive Iterable API.

There are some points in the other direction:

- I believe unconditionally calling `IntoIterator` (i.e. not dectecting and handling `Iterator`s specially) will stop https://github.com/rust-lang/rust/issues/8372 being possible, since the iterator `for ... in iter { ... }` wlll be moved (or duplicated) and thus either `iter` will not be usable in the body, or it will not refer to the same thing as the for loop head.

- Some containers can only provide `&`, i.e. `&` is the lowest common denominator.

- On that note, it is weird that `for x in v` is by value for `Vec` but by reference for `&[]` (and there's a similar difference for `for x in map` e.g. if `map` is a function argument that is passed as `&HashMap<...>` vs. if it is a local).

- 
    > If we make sure that programmers are made aware of that from their first encounter with iteration, I think it's unlikely that they'd reach for .clone.

  Well, people do a lot of passing `Vec` and `String` by value now, even when they could just pass `&` if not `&str` or `&[]`; maybe that's just a problem with our documentation.