Decide on story about `box` for 1.0 alpha (and 1.0 final)

[nikomatsakis]

We've let the matter of box slip too long. Nobody is happy with its current state, I think, but the final direction is perhaps not quite clear.

Some problems are:

1. The syntax box(place) expr is ambiguous. in(place) expr has been proposed as an alternative.
2. Having box expr be tied to Box<T> is not great. Using inference has been proposed as an alternative.
3. The protocol should be extensible. @pnkfelix has a proposal but there has been some pushback that the protocol might be cleaner given hypothetical future language features.

Options I see:

1. Feature-gate box completely for now, adding a Box::new function.
2. Implement the protocol @pnkfelix designed, but declare it unstable. The idea is to prevent people from implementing the protocol themselves or using it directly. This is similar to what we are doing for the Fn traits.
3. Implement the protocol @pnkfelix designed and commit to it.

The actual path we want to take can be a combination of the above options. i.e., we might feature-gate for now, but do option 2 during beta period.

I think that whatever we do, we should ensure that we do not ship with box(foo) expr permitted in stable code.

[nikomatsakis]

Note: you might think we could just feature gate box with a placer expression, but that would not be forwards compatible with using inference in the future.

[nikomatsakis]

However, if we think we want to commit to option 2 or 3, we could probably get away with doing next-to-nothing for alpha and instead just doing full impl during beta. I believe the impact was found to be relatively minimal. (Maybe @pnkfelix or @eddyb can confirm/deny?)

[alexcrichton]

box is now gated.