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
Doc: Clears up trim_char doc

Closes #18451
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
Add a `repeat` function to the prelude

Implements a part of RFC 235.

[breaking-change]
Really fix #17982 this time.
rustc: Implement -l and include! tweaks

This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new
flag to the compiler, `-l`, as well as tweaking the `include!` macro (and
related source-centric macros).

The compiler's new `-l` flag is used to link libraries in from the command line.
This flag stacks with `#[link]` directives already found in the program. The
purpose of this flag, also stated in the RFC, is to ease linking against native
libraries which have wildly different requirements across platforms and even
within distributions of one platform. This flag accepts a string of the form
`NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework.
This is roughly equivalent to if the equivalent `#[link]` directive were just
written in the program.

The `include!` macro has been modified to recursively expand macros to allow
usage of `concat!` as an argument, for example. The use case spelled out in RFC
403 was for `env!` to be used as well to include compile-time generated files.
The macro also received a bit of tweaking to allow it to expand to either an
expression or a series of items, depending on what context it's used in.

[rfc]: https://github.com/rust-lang/rfcs/pull/403
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.
DSTify ToCStr
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
debuginfo: Make GDB tests use line breakpoints like done in LLDB tests.

On some Windows versions of GDB this is more stable than setting breakpoints via function names.
debuginfo: Enable some GDB tests on Windows.
DOC: improves the str type explanation

Closes #18449