This permits all coercions to be performed in casts, but adds lints to warn in those cases.

Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.

[breaking change]

* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:

```
let x = 42;
let y = &x as *const u32;
```

Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:

```
let x: u32 = 42;
let y = &x as *const u32;
```

for `&mut (Trait+'a)` to `&mut (Trait+'b)` if `'a:'b`.

Fixes #14985.

This upcast coercion currently preserves the vtable for the object, but
eventually it can be used to create a derived vtable. The upcast
coercion is not introduced into method dispatch; see comment on #18737
for information about why. Fixes #18737.

fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].

fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.

This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.

Part of #20013

[breaking-change]

This makes sty only 32 bytes on machines with 64-bit pointers.

This cuts the ty_bare_fn variant to 48 bytes rather than 56. There
doesn't seem to be a noticable memory usage decrease from this.

This current inflates memory use more than 3 times.

type of a fn item or a fn pointer, which are now differentiated.
Introduce coercion from fn item to fn pointer.

have such a silly over-engineered interface.

Fix bug in higher-ranked code that would sometimes leak skolemized regions and/or cause incorrect results.

Sister pull request of https://github.com/rust-lang/rust/pull/19288, but
for the other style of block doc comment.

[breaking-change]

Insert an `&` to fix

Make TyTrait embed a `TraitRef`, so that when we extend TraitRef, it naturally carries over to object types.

I wanted to embed an `Rc<TraitRef>`, but I was foiled by the current
static rules, which prohibit non-Sync values from being stored in
static locations. This means that the constants for `ty_int` and so
forth cannot be initialized.

Also:
1. stop eagerly coercing from `[T, ..n]` to `[T]` only do so if requested.
2. permit error to be interact more freely.

Fixes #17178.