This removes the Cell from AdtDef. Also, moving destructor validity
checking to on-demand (forced during item-type checking) ensures that
invalid destructors can't cause ICEs.

Fixes #38868.
Fixes #40132.

I'll like @nikomatsakis or someone to look at the unsolved variable
case.

Fixes #27901.
Fixes #28828.
Fixes #38135.
Fixes #39363.

Fixes #40085

	* use more convenient mk_substs function
	* remove type annotations
	* use map_bound one level farther outside
	* style improvements

Re: 48b3dd11

They now always say how many lifetime / type parameters were expected
and are explicit about stating "lifetime" or "type" instead of just
"parameter".

Closes #39732

As per comment: https://github.com/rust-lang/rust/issues/39297#issuecomment-276810343

This is the full and proper fix for #32330. This also makes some effort
to give a nice error message (as evidenced by the `ui` test), sending
users over to the tracking issue for a full explanation.

The previous way was not friendly to incremental compilation. The new
plan is to compute, for each body, a set of trait imports used in that
body (slightly subtle: for a closure, we assign the trait imports to the
enclosing fn). Then we walk all bodies and union these sets. The reason
we do this is that we can save the individual sets in the incremental
state, and then recompute only those sets that are needed. Before we
were planning to save only the final union, but in that case if some
components are invalidated we have to recompute *all* of them since we
don't have enough information to "partly" invalidate a result.

In truth, this set probably ought to be part of the `TypeckTables`;
however, I opted not to do that because I don't want to have to
save/restore the entire tables in the incremental state yet (since it
contains a lot of `NodeId` references, and removing those is a
significant refactoring).

Otherwise they are a "hidden output"

This is the first part of #39018. One of the common things for new users
coming from more dynamic languages like JavaScript, Python or Ruby is to
use `+` to concatenate strings. However, this doesn't work that way in
Rust unless the first type is a `String`. This commit adds a check for
this use case and outputs a new error as well as a suggestion to guide
the user towards the desired behavior. It also adds a new test case to
test the output of the error.