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 wonder if we would lose anything by adding `extend_one` to `Extend` (we could even have `reserve_additional` on it, and have a default impl for `extend`). "Lose" in the sense of restricting the number of types that can implement the trait; it certainly doesn't seem like it, since `foo.extend_one(x);` is isomorphic to `foo.extend(Some(x).into_iter())`.