Replace current quasi-subtyping relationship for object types with coercions

[nikomatsakis]

Currently the type checker considers A+Send to be a subtype of A, but not for the purposes of inference. Part of the DST / coercion plan was to generalize this into a coercion relationship so that it can accommodate arbitrary traits. We should do this before 1.0 as it will cause various minor bits of breakage. Among other things, method resolution will have to be adapted to accommodate this change.

cc @nick29581

[nikomatsakis]

Nominating for P-backcompat-lang, 1.0.

[pnkfelix]

P-backcompat-lang, 1.0, but its possible that this is lesser priority than other P-backcompat-lang issues (i.e. we may be able to hold off on fixing this until the beta period).

[nikomatsakis]

If push came to shove, we could live with this behavior.

[aturon]

Nominating. It sounds like this should not be on the -beta milestone, but we should discuss.

[pnkfelix]

Assigning 1.0-beta milestone based on potential for breaking lots of code according to nrc.

[alexcrichton]

An example that this may fix (or maybe a good smoke test)

pub trait Any: 'static {}
pub struct Box2<T: ?Sized>(Box<T>);

impl Box2<Any> {
    pub fn foo(self) {}
}

fn t2(t: Box2<Any + Send>) {
    t.foo(); // type `Box2<Any + Send>` does not implement any method in scope named `foo`
} 

This is largely in relation to the BoxAny trait we currently have.