User-defined placement-box

Add support for user-defined placement-box expressions (i.e. `box (<place>) <value>` for types other than `Box<T>`).

This is a prototype design that @nikomatsakis and @pnkfelix have been working on.  It works by desugaring an instance of placement-box into a protocol where we first create the intermediate storage with a pseudo-out-pointer, then initialize the storage, and then convert the out-pointer into the desired box type.

The code was originally written to handle both `box (<place>) <value>` and `box <value>` via the same uniform desugaring, and it is easy to revise support for the latter; but as is, this PR only puts `box (<place>) <value>` into the desugaring.  The reason for this is that the error messages get a lot nastier to handle from the desugared form, and pnkfelix did not want to hold this work up further trying to resolve that.

The final design for this will require an RFC; this code is entirely experimental for now.

Proto RFC: http://discuss.rust-lang.org/t/pre-rfc-placement-box-with-placer-trait/729/5
With the current design, `make_place` could be called repeatedly, and so that would result in aliasing `&mut`s. However, there are other problems with calling `make_place` repeatedly. Since `reserve_additional` reserves space relative to the length of the vector, multiple `make_place`s will only reserve space for a single extra element. The `assert`s in `.pointer` prevent unsafety, but it still is an issue. Arguably worse, the implication of the description of `.pointer` implies that different `PlacementAgent`s should return different pointers, but this is violated by having multiple `EmplaceBackAgent`s on the same `Vec`.

Personally, I'm in favor of just making `make_place` take the `Placer` by value. This shouldn't hurt ergonomics, as `HEAP` and `RC` would be `Copy`.