Improve the readability of diagnostics that involve unresolved type variables

Diagnostics such as the following

```
mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7     f(42u);
               ^~~
```

tend to be fairly unappealing to new users. While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.

In addition, type variables have been changed to use the type hole syntax `_` in diagnostics.
With a variable ID, they're printed as `_#id` (e.g. `_#1`). In cases where the ID is left out,
it's simply `_`. Integer and float variables have an additional suffix after the number, e.g.
`_#1i` or `_#3f`.
Update tests with the new diagnostic tweaks
Address review comments
Always drop var IDs from type variables modulo -Z verbose, per PR discussion
Add a test for failure to unify type parameters
Add a test for errors unifying an integer variable with a float variable
Use the `_` representation for integral variables as well
DSTify Show and all the other formatting traits
auto merge of #18431 : japaric/rust/show, r=alexcrichton

r? @aturon 
cc #16918
auto merge of #18264 : jakub-/rust/var-ids-in-error-messages, r=nikomatsakis

This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following:

```rust
mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7     f(42u);
               ^~~
```

tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.

```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut _`, found `uint`
<anon>:7     f(42u);
               ^~~
```

As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is:

```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>`
<anon>:6     let a: Result<uint, ()> = Some(1);
```

and float variables:

```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>`
<anon>:6     let a: Result<uint, ()> = Some(0.5);
```

[0] https://twitter.com/coda/status/517713085465772032

Closes https://github.com/rust-lang/rust/issues/2632.
Closes https://github.com/rust-lang/rust/issues/3404.
Closes https://github.com/rust-lang/rust/issues/18426.
DSTify Hash

- The signature of the `*_equiv` methods of `HashMap` and similar structures
have changed, and now require one less level of indirection. Change your code
from:

```
hashmap.find_equiv(&"Hello");
hashmap.find_equiv(&&[0u8, 1, 2]);
```

to:

```
hashmap.find_equiv("Hello");
hashmap.find_equiv(&[0u8, 1, 2]);
```

- The generic parameter `T` of the `Hasher::hash<T>` method have become
`Sized?`. Downstream code must add `Sized?` to that method in their
implementations. For example:

```
impl Hasher<FnvState> for FnvHasher {
    fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
}
```

must be changed to:

```
impl Hasher<FnvState> for FnvHasher {
    fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
    //      ^^^^^^
}
```

[breaking-change]
trans: use types from argument patterns instead of the function signature.

This fixes ICEs caused by late-bound lifetimes ending up in argument
datum types and being used in cleanup - user Drop impl's would then
fail to monomorphize if the type was used to look up the impl of a
method call - which happens in trans now, I presume for multidispatch.
auto merge of #18458 : eddyb/rust/free-region-args, r=nikomatsakis

This fixes ICEs caused by late-bound lifetimes ending up in argument
datum types and being used in cleanup - user Drop impl's would then
fail to monomorphize if the type was used to look up the impl of a
method call - which happens in trans now, I presume for multidispatch.
auto merge of #18440 : japaric/rust/hash, r=alexcrichton

- The signature of the `*_equiv` methods of `HashMap` and similar structures have changed, and now require one less level of indirection. Change your code from:

``` rust
hashmap.find_equiv(&"Hello");
hashmap.find_equiv(&&[0u8, 1, 2]);
```

to:

``` rust
hashmap.find_equiv("Hello");
hashmap.find_equiv(&[0u8, 1, 2]);
```

- The generic parameter `T` of the `Hasher::hash<T>` method have become `Sized?`. Downstream code must add `Sized?` to that method in their implementations. For example:

``` rust
impl Hasher<FnvState> for FnvHasher {
    fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
}
```

must be changed to:

``` rust
impl Hasher<FnvState> for FnvHasher {
    fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
    //      ^^^^^^
}
```

[breaking-change]

---

After review I'll squash the commits and update the commit message with the above paragraph.

r? @aturon 
cc #16918
Teach variance checker about the lifetime bounds that appear in trait object types.
Resolve methods called as functions and...

...defined in another crate.

Fixes #18061
Remove FnStyle from DefFn and DefStaticMethod
Cross crait inherant impls
test
Rebasing and review changes