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)
Higher-ranked types and higher-kinded types are similar in some ways, but still have very different implications for the type system.

A higher-ranked type is still just a type, i.e. a thing that classifies values directly. You still write `f: F` in your example.

A higher-*kinded* type, by contrast, may not be a type at all: it may be a function from types to types. For example, `Vec<u8>` is a type (has kind Type) while `Vec` is a type constructor (has kind `Type -> Type`).

Higher-ranked types are easier to add because they're just saying that a value could've been given *many* different types, but otherwise don't really change the mechanics of type or borrow checking. Higher-kinded types, in contrast, are a much deeper change to how you talk about types in general.

In any case, higher-ranked types don't solve the problem with iterator types, because you need to be able to say you're returning an iterator with a *specific* lifetime parameter, and the only way to do that is for the iterator type to have kind `Lifetime -> Type`.