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)
It's an open question: there are [several](https://github.com/rust-lang/rfcs/pull/226) [proposals](https://github.com/rust-lang/rfcs/pull/241) in flight that would make even the `&*` noise unnecessary. It's difficult to tease apart all these questions.

I've come around to the idea of `Vec` and `String` as smart pointer types, and that provides the cleanest way to ensure that the slice functionality is always available as methods on these types.

I think that, if this RFC lands as-is, we *will* want to remove the `[]` slicing notation, either providing `[..]`, or else nothing, in its place. But I think that should be a separate follow-up, because there are other reasons to want deref here.