Unboxed closures

A relatively complete description of by reference closures that aims to encompass entirety of current thinking, except for bound lifetimes.

cc @pcwalton
Also, I was quite torn when I realized this consequence; it makes the closure sugar feel a little less sugar-y.  I have been wondering if we should consider saying that the closure sugar expands into the corresponding `Fn` variant, but with a leading `impl` from #105 as well.

So with that suggestion in place, this sugared code under the new regime:
```
fn doubled(f: |int| -> int) -> |int| -> int { |x| { f(f(x)) } }
```
would be desugared into:
```
fn doubled(f: impl Fn<(int,), int>) -> impl Fn<(int,),int> { |x| { f(f(x)) } }
struct Fresh<F:Fn<(int,), int>> { f: F }
impl Fn<(int,), int> for Fresh { fn call(&mut self, (x,) : (int,)) -> int { self.f(self.f(x)) }
```
rather than requiring the user to write 
`fn doubled(f: impl |int| -> int) -> impl |int| -> int { |x| { f(f(x)) } }`

To get today's semantics of dynamically-dispatched closure types, under my suggested changes you would be forced to write `&Fn<(T1,..,Tk), R>` (or perhaps just `&Fn<(T1,...,Tk)> -> R` if that side-proposal goes through).

----

I do not know, it is hard for me to gauge how painful each of these options are.  I guess I just mention this to point out that the sugar, as proposed, is not adding that much.  But on the other hand, the change I am proposing would force a lot of people's current code to change (that, or force it to start behaving quite a bit differently with respect to generated code size and what not).

And also, I will admit that while I say above that the proposed sugar is not adding "that much", there is another point-of-view of the proposed sugar that in fact it adds "just enough".