Numeric type module constants should be moved into inherent impls

[lilyball]

All of the methods provided on our numeric types are part of the inherent impls found in core::num. But the various constants provided for these types (e.g. usize::MAX, i8::MIN, f32::EPSILON) are vended as part of modules named after the types. This seems like it should no longer be necessary now that we have associated constants, and it's confusing because clicking on the documentation for a primitive type (e.g. usize) doesn't show these constants.

[lilyball]

The numeric type modules and their constants are marked as #[stable], which poses a problem for moving the constants. Experimentally, it seems that if a type and a module share a name and both define the same constant, references to the constant via the type name ends up resolving to the module constant (as opposed to throwing an ambiguity error). I don't know if this is intentional, or is actually a bug, but it does mean that we could simply duplicate the constants into the inherent impls and no existing code would break. We could then consider deprecating the constants in the numeric modules (and the modules themselves for the integral types, but not for f32 and f64 as those both have a submodule consts).

[lilyball]

/cc @aturon

[lilyball]

Also see rust-lang/rust#23947 which suggests the addition of these associated consts.

[petrochenkov]

I tried to do this today, but encountered an ICE
rust-lang/rust#24938

[petrochenkov]

I think it's a minor enough breaking change to move the constants and deprecate the modules u8, u16, etc. Not so sure about removing these modules entirely, I'd appreciate that, but it'll break all the code use-ing them.

[bstrie]

Spongebob Narrator voice: "Four years later."