Repair various cases where values of distinct types were being operated
upon (e.g., `&int` added to `int`).
Add impls of the comparison operators for fixed-length arrays of lengths 0...32 and repair various cases where slices and fixed-length arrays were being compared.
Implement new operator dispatch semantics.

Key points are:
1. `a + b` maps directly to `Add<A,B>`, where `A` and `B` are the types of `a` and `b`.
2. Indexing and slicing autoderefs consistently.
Update the guide examples and try not to leave user hanging as to what
this `&x` sigil is all about.
Remove incorrect doc annotation, mark experimental since we haven't discussed in an API meeting
Better debug printouts
auto merge of #18486 : nikomatsakis/rust/operator-dispatch, r=pcwalton

This branch cleans up overloaded operator resolution so that it is strictly based on the traits in `ops`, rather than going through the normal method lookup mechanism. It also adds full support for autoderef to overloaded index (whereas before autoderef only worked for non-overloaded index) as well as for the slicing operators.

This is a [breaking-change]: in the past, we were accepting combinations of operands that were not intended to be accepted. For example, it was possible to compare a fixed-length array and a slice, or apply the `!` operator to a `&int`. See the first two commits in this pull-request for examples.

One downside of this change is that comparing fixed-length arrays doesn't always work as smoothly as it did before. Before this, comparisons sometimes worked due to various coercions to slices. I've added impls for `Eq`, `Ord`, etc for fixed-lengths arrays up to and including length 32, but if the array is longer than that you'll need to either newtype the array or convert to slices. Note that this plays better with deriving in any case than the previous scheme.

Fixes #4920.
Fixes #16821.
Fixes #15757.

cc @alexcrichton 
cc @aturon
Use operator sugar in the expansion of `#[deriving(PartialEq)]`
Fix fallout of changing the expansion of `#[deriving(PartialEq)]`
DSTify PartialEq, PartialOrd, Eq, Ord
Fix fallout of DSTifying PartialEq, PartialOrd, Eq, Ord
DSTify Box<T> implementation of PartialEq, PartialOrd, Eq, Ord
Add test for the first half of issue #15689

cc #15689
Fix tests
Add blanket impls to allow the various `Fn` traits to be interconverted.

Fixes #18387.
Reverse order of lookup
Partial fix for #17901: Be less conservative around unbound type
variables in the intracrate case. This requires a deeper distinction
between inter- and intra-crate so as to keep coherence working.

I suspect the best fix is to generalize the recursion check that
exists today, but this requires a bit more refactoring to achieve.

(In other words, where today it says OK for an exact match, we'd want
to not detect exact matches but rather skolemize each trait-reference
fresh and return AMBIG -- but that requires us to make builtin bounds
work shallowly like everything else and move the cycle detection into
the fulfillment context.)
Correct tests that were supposed to fail but now pass due to the fn trait hierarchy.
auto merge of #18388 : nikomatsakis/rust/fn-trait-hierarchy, r=acrichto

Add blanket impls to allow the various `Fn` traits to be interconverted.

Fixes #18387.
auto merge of #18467 : japaric/rust/eq, r=alexcrichton

`eq`, `ne`, `cmp`, etc methods now require one less level of indirection when dealing with `&str`/`&[T]`

``` rust
"foo".ne(&"bar") -> "foo".ne("bar")
slice.cmp(&another_slice) -> slice.cmp(another_slice)
// slice and another_slice have type `&[T]`
```

[breaking-change]