Add OpAssign to Wrapping<T>, plus fix some problems in core::num::wrapping

including, but not limited to:

* Testing Wrapping<T>
* Pull out a lot of broken code that doesn't need to be there with the new stage0 compiler
* Adding Rem and RemAssign to Wrapping<T>
* Removed 3 (assumed accidental) re-exports, which is a minor [breaking-change].
* Change shl and shr to take all integer types, instead of a usize; this is a more major [breaking-change], because of values that were inferred before, but brings us in line with the integer shifts.

Fixes #30524 and #30523

Fixes #30527.

```Rust

fn main() {
    let _abc = match Some(101i8) {
        Some(xyz) if xyz > 100 => xyz,
        Some(_) => -1,
        None => -2
    };
}
```

Resulting MIR now includes the `Some(xyz)` arm, guard and all:
![match.dot](https://cloud.githubusercontent.com/assets/287063/11999413/066f7610-aa8b-11e5-927b-24215af57fc4.png)

~~Not quite sure how to write a test for this.~~ Thinking too hard, just tested the end result.

r? @nikomatsakis

`fs::File` was being referenced without either calling via `std::fs::File` or by using `File` after having used `std::fs::File`.  Also `Path` was being referenced without first having used `std::path::Path`.

fs::File was being referenced without either calling via std::fs::File or by using File after having used fs::File.  Also Path was being referenced without first having used std::path::Path.

This is not a fix to checks themselves per se (though we still use `Eq` MIR test instead of calling `PartialEq::eq`), but rather how we handle items we encounter in pattern position.

Previously we would just call `PartialEq` with the constant and the matchee, but now we essentially inline the constant instead. E.g. these two snippets are functionally equivalent at MIR level:

```
match val { Some(42) => true, _ => false }
```
and
```
const SECRET: Option<u8> = Some(42);
match val { SECRET => true, _ => false }
```

This approach also allows for more optimizations of matches. I.e. It can now exploit `SwitchInt` to switch on number inside a `Some` regardless of whether the value being an item or not.

This is based on @tsion’s already approved PR so I could reuse the file for more tests.

r? @EddyB
cc @nikomatsakis @tsion

Obviously we can't remove the character one past the end of the String. And we can't today either - we'll just panic at char_at() instead - but if we're going to keep that assertion, we should at least have a correct assertion.

This PR for #21659 uses `DefId.for_each_relevant_impl()` to show other possible implementations in the "trait not implemented" message.

Obviously we can't remove the character one past the end of the String. And we can't today either - we'll just panic at char_at() instead - but if we're going to keep that assertion, we should at least have a correct assertion.

r? @Manishearth

Also: should I merged both commits? Not sure if it's really useful to keep the first one.

f64 methods have been stable since rust 1.0, but f32 never got stabilised.

I suggest backporting this to beta as well (needs changing stablilisation version then).

r? @aturon

Fixes https://github.com/rust-lang/rfcs/issues/1438

f64 methods have been stable since rust 1.0, but f32 never got stabilised.

closes #21659

When looking in the documentation I often scan the examples the first thing I do. In these 3 cases it's not obvious which direction the operation happens by adding this comment it makes it more obvious.

r? @steveklabnik

CC #30642

r? @Gankro

Are trait impls still insta-stable? Considering that this design has been around for a long time on `String` and `OsString` it probably doesn't matter much...

The `From` impl is a bit strange to me. It's stolen from `OsString` but I'm not really sure about it... `String` just impls `From<&str>` instead, would that make more sense?

CC #30642

- Successful merges: #30365, #30565, #30590, #30630
- Failed merges:

Previously, all references to closure arguments went to the argument before the one they should (e.g. to `arg1` when it was supposed to go to `arg2`). This was because the MIR builder did not account for the implicit arguments that come before the explicit arguments, and closures have one implicit argument - the struct containing the captures.

This is my test code and a diff of the MIR generated for the closure:

```rust
let a = 2i32;
let _f = |b: i32| -> i32 { a + b }:
```

```diff
--- old	2015-12-29 23:16:32.027926372 -0600
+++ new	2015-12-29 23:16:42.975400757 -0600
@@ -1,22 +1,22 @@
 fn(arg0: &[closure@closure-args.rs:8:14: 8:39 a:&i32], arg1: i32) -> i32 {
     let var0: i32; // b
     let tmp0: ();
     let tmp1: i32;
     let tmp2: i32;

     bb0: {
-        var0 = arg0;
+        var0 = arg1;
         tmp1 = (*(*arg0).0);
         tmp2 = var0;
         ReturnPointer = Add(tmp1, tmp2);
         goto -> bb1;
     }

     bb1: {
         return;
     }

     bb2: {
         diverge;
     }
 }
```

(If you're wondering where this text MIR output comes from, it's from another branch of mine waiting on https://github.com/rust-lang/rust/pull/30602 to get merged.)