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)
A couple of points here:

1. I don't see any simple way to make `for` use an `Iterable`-style API that defaults to by-reference, for reasons that I outlined [here](https://github.com/aturon/rfcs/blob/collections-conventions/active/0000-collections-conventions.md#handling-of-for-loops). Basically, an iterator can only implement a by-value `Iterable` API.

  Please let me know if you see a way around this, though.

2. In terms of shaping what people do, note that the ergonomics of `for x in v` and `for x in &v` are almost identical. So I think the main thing is documentation. When we first introduce iteration in the docs, we would surely show `for x in &v` and explain what the `&` is doing. 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`.

3. Moving is the default almost everywhere in Rust. To me, writing `for x in &v` serves as a nice signal to the reader that references are being taken. It also plays quite nicely with the [deref coercions](https://github.com/rust-lang/rfcs/pull/241) that I've recently proposed.