rand_distr: no_std support

[dhardy]

As @burdges and @kennytm recently pointed out, rand_distr currently depends on std for various mathematical functions (trig, exp).

Status: std provides these functions over the platform's native libm lib.

Available alternative: libm is a pure-Rust port of MUSL's libm. We could target this, perhaps behind a feature flag. I'm not sure whether we want to go this route.

See also: Portability of floats. Would use of the pure-Rust libm implementation address this?

[vks]

Maybe we should just use num_traits::float::Float, which gives us no_std support using libm for free.

[dhardy]

My POV is that whatever we do, we make an explicit choice and not just use something, since this affects reproducibility (admittedly, only in cases where reproducibility is already hard to assure).

API cost is not really an issue here anyway (producing our own wrapper would be easy).

[burdges]

I think this sounds cool. Ain't clear if anyone needs this anytime soon, but I suppose exp comes up lots.

I agree that floats portability sounds like a bigger deal, but no idea if/where that should be addressed.

It plausible that many folks who want this actually want discrete distributions anyways, like negative binomial, etc., so maybe doing those clean first makes the most sense?