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.
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
Fix RustDoc bug
auto merge of #18177 : nick29581/rust/ufcs2, r=nikomatsakis

r?

closes #18061
auto merge of #18371 : nikomatsakis/rust/issue-18262, r=pcwalton

Teach variance checker about the lifetime bounds that appear in trait object types.

[breaking-change] This patch fixes a hole in the type system which resulted in lifetime parameters that were only used in trait objects not being checked. It's hard to characterize precisely the changes that might be needed to fix target code.

cc #18262 (this fixes the test case by @jakub- but I am not sure if this is the same issue that @alexcrichton was reporting)

r? @pnkfelix 

Fixes #18205
auto merge of #18422 : michaelwoerister/rust/windows-freeze-fix, r=alexcrichton

On some Windows versions of GDB this is more stable than setting breakpoints via function names. This is also something I wanted to do for some time now because it makes the tests more consistent.

@brson:
These changes are in response to issue #17540. It works on my machine with the toolchain mentioned in the issue. In order to find out if the problem is really worked around, we also need to make the build bots use the newer GDB version again.
auto merge of #18457 : japaric/rust/tocstr, r=alexcrichton

Methods that used to take `ToCStr` implementors by value, now take them by reference. In particular, this breaks some uses of `Command`:

``` rust
Command::new("foo");  // Still works
Command::new(path) -> Command::new(&path)
cmd.arg(string) -> cmd.arg(&string) or cmd.arg(string.as_slice())
```

[breaking-change]

---

It may be sensible to remove `impl ToCstr for String` since:
- We're getting `impl Deref<str> for String`, so `string.to_cstr()` would still work
- `Command` methods would still be able to use `cmd.arg(string[..])` instead of `cmd.arg(&string)`.

But, I'm leaving that up to the library stabilization process.

r? @aturon 
cc #16918
libserialize: tuple-arity should be provided to `Decoder::read_tuple`

Currently `Decoder` implementations are not provided the tuple arity as
a parameter to `read_tuple`. This forces all encoder/decoder combos to
serialize the arity along with the elements. Tuple-arity is always known
statically at the decode site, because it is part of the type of the
tuple, so it could instead be provided as an argument to `read_tuple`,
as it is to `read_struct`.

The upside to this is that serialized tuples could become smaller in
encoder/decoder implementations which choose not to serialize type
(arity) information. For example, @TyOverby's
[binary-encode](https://github.com/TyOverby/binary-encode) format is
currently forced to serialize the tuple-arity along with every tuple,
despite the information being statically known at the decode site.

A downside to this change is that the tuple-arity of serialized tuples
can no longer be automatically checked during deserialization. However,
for formats which do serialize the tuple-arity, either explicitly (rbml)
or implicitly (json), this check can be added to the `read_tuple` method.

The signature of `Deserialize::read_tuple` and
`Deserialize::read_tuple_struct` are changed, and thus binary
backwards-compatibility is broken. This change does *not* force
serialization formats to change, and thus does not break decoding values
serialized prior to this change.

[breaking-change]
Tuple deserialization should not fail