Unboxed closures

A relatively complete description of by reference closures that aims to encompass entirety of current thinking, except for bound lifetimes.

cc @pcwalton
If we don't have a subtyping relationship on the closure traits, then we'll just end up with a needless variants of higher-order functions.

For example, if I want to write `foo(f: ||) { f(); f(); }` and I don't really care whether `f` mutates its environment or not, then I'd like to be able to pass both `Fn<(),()>` and `FnShare<(),()>` to `foo`. But I can't do that because there's no subtyping! Instead I'll need to provide `foo_imm(f: |&:|) { f(); f(); }` and `foo_mut(f: |&mut:|) { f(); f(); }`. If I only called `f` once in the body of `foo`, then I'd need to add a `foo_once` version as well to be as general as possible. If I have multiple closures involved, then I'll need to provide variants for **every permutation** of the relevant types. This gets out of hand very quickly.

Not having subtyping will either:
- Create this entirely pointless explosion of variants
- Encourage people to put an artificially restrictive `Fn` bound on an otherwise `FnShare`able closure because no one is bothering to write the `FnShare` variants. `FnOnce` would probably still be used due to its utility so we'd have the `foo` / `foo_once` explosion still.
- No one bothers to make variants at all and we have to explain forevermore why you can't pass your closure to this function when it's perfectly safe to do so.

Yeah it's weird if people implement the traits with different bodies, but it's not any different than when people don't follow the rules for other kind of operator overloading. Slightly different bodies are actually necessary for a `FnOnce` instance versus `Fn`/`FnShare` because of the values vs refs.