Unboxed closures

A relatively complete description of by reference closures that aims to encompass entirety of current thinking, except for bound lifetimes.

cc @pcwalton
Not just `Trait(A, B) -> C`, but any `Type(A, B) -> C`. The reason I prefer this approach is that there are too many degrees of freedom in the closure types to be able to capture enough of them with specific built-in sugar. There's the trait itself *and* the containing type in the case of boxed closures *and* additional (built-in) trait bounds, and possibly lifetimes as well.

If `|:&mut T1...Tn| -> R` is sugar for a trait, then if you wish to pass a boxed mutable closure (incidentally the only type of closure currently in the language besides `proc`), do you have to write `&mut |:&mut int| -> int`? That's somewhat unsightly. If we make the sugar refer to a boxed closure instead to address this case, then we wouldn't have sugar for unboxed closures. We could try to make a typedef for it: `type MutFn<'s, A, R> = &'s mut |:&mut A| -> R`, but then we lose the sugar.

With the generic sugar, we can write:

    trait FnMut(A) -> R {
        ...
    }

*and* we can use the same sugar to make typedefs as well, for instance our earlier boxed mutable closure:

    type MutFn(A) -> R = &mut FnMut(A) -> R;

(There are still some things that need to be thought through for this idea: for instance, I don't know where to put the `'s` lifetime in the above typedef.)

and we can also recover the current `proc` type, if we feel like it:

    type Proc(A) -> R = Box<FnOnce(A) -> R + Send>;

And in general, users can use the sugar to make sweet-looking typedefs for whichever sorts of closures are employed frequently in the given API, relieving the language itself of the responsibility to try to anticipate all of them.