Generalize object and type parameter bounds

[nikomatsakis]

Implements rust-lang/rfcs#192.

In particular:

1. type parameters can have lifetime bounds and objects can close over borrowed values, presuming that they have suitable bounds.
2. objects must have a bound, though it may be derived from the trait itself or from a Send bound.
3. all types must be well-formed.
4. type parameters and lifetime parameters may themselves have lifetimes as bounds. Something like T:'a means "the type T outlives 'a" and something like'a:'b`" means "'a outlives 'b". Outlives here means "all borrowed data has a lifetime at least as long".

This is a [breaking-change]. The most common things you have to fix after this change are:

1. Introduce lifetime bounds onto type parameters if your type (directly or indirectly) contains a reference. Thus a struct like struct Ref<'a, T> { x: &'a T } would be changed to struct Ref<'a, T:'a> { x: &'a T }.
2. Introduce lifetime bounds onto lifetime parameters if your type contains a double reference. Thus a type like struct RefWrapper<'a, 'b> { r: &'a Ref<'b, int> } (where Ref is defined as before) would need to be changed to struct RefWrapper<'a, 'b:'a> { ... }.
3. Explicitly give object lifetimes in structure definitions. Most commonly, this means changing something like Box<Reader> to Box<Reader+'static>, so as to indicate that this is a reader without any borrowed data. (Note: you may wish to just change to Box<Reader+Send> while you're at it; it's a more restrictive type, technically, but means you can send the reader between threads.)

The intuition for points 1 and 2 is that a reference must never outlive its referent (the thing it points at). Therefore, if you have a type &'a T, we must know that T (whatever it is) outlives 'a. And so on.

Closes #5723.

[nikomatsakis]

r? @pnkfelix

Note: there are still a lot of commits here. I got tired of grouping them together. I will likely come back and group them some more later, but I'd also like to walk you through the code a bit.

[nikomatsakis]

Per discussion with @nick29581 and @pnkfelix, we're going to delay review (or at least landing) somewhat so as to try and avoid conflicts with DST branch.

[nikomatsakis]

OK, I cleaned up the set of commits, grouping things together as best I could. It's reasonably clean now, though the commits will not build independently.

[nikomatsakis]

Closes #16462

[nikomatsakis]

Rebased over DST. At this point the history is ruined, so I squashed down to a single commit now that the review has been done.