Unconditionally bound with T: FloatCore.

Previously, the `std` feature was non-additive; that is, it was
possible for *enabling* the `std` feature to break code in another
crate. Specifically, consider the following code:

    fn problem<T>(inputs: &mut [OrderedFloat<T>])
    where
        T: num_traits::float::FloatCore,
    {
        inputs.sort();
    }

This code will compile if the `std` feature is disabled, but then fail
when it is enabled because `Ord for OrderedFloat<T>` requires that
`T: Float`, rather than `T: FloatCore`.

In order to eliminate this compatibility hazard, instead always
require `FloatCore` and, where necessary, also require `Float`.

**This is a breaking change;** generic code may need updated bounds.

Also, for reasons I do not entirely understand, `#[derive(PartialEq)]`
wouldn't compile for the `UniformNotNan` and `UniformOrdered`
distribution types, so I had to replace them with ones with explicit
bounds. This may be a sign that something deeper is wrong, or it might
be an inadequacy of the rustc trait solver...