RFC: numerics reform

This RFC is preparation for API stabilization for the `std::num` module.  The goal is to finish the simplification efforts started in [@bjz's reversal of the numerics hierarcy](https://github.com/rust-lang/rust/issues/10387).

Broadly, the proposal is to collapse the remaining numeric hierarchy in `std::num`, and to provide only limited support for generic programming (roughly, only over primitive numeric types that vary based on size).  Traits giving detailed numeric hierarchy can and should be provided separately through the Cargo ecosystem.

Thus, this RFC proposes to flatten or remove most of the traits currently provided by `std::num`, and generally to simplify the module as much as possible in preparation for API stabilization.

[Rendered](https://github.com/aturon/rfcs/blob/num-reform/active/0000-num-reform.md)
Some of these have worried me in the past in the sense that although they are LLVM intrinsics, they're often lowered to function calls at compile-time into libraries like `libm`. By providing these functions in libcore we're semi-stating that they're available for everyone forever (some of them do have x86 instructions, for example), but we're not necessarily delivering on that statement.

A small wory, just wanted to point out why these are singled out for being in libcore rather than libstd. Anyone using these functions and libcore directly will likely already know how to get them anyway