Move thread RNG into a separate crate

[newpavlov]

This was previously discussed in #716 and recently raised in #1514.

The main disadvantage of moving thread RNG into its own crates is that users of rand (with default crate features) will have one additional dependency in their dependency tree. On the other hand, ThreadRng can be now used without the rest of rand (e.g. in cryptographic applications). It also results in simpler configuration flags and thread RNG code, since we don't need to deal with the generality of ReseedingRng.

If ReseedingRng is not used in practice (cursory search on GitHub shows mostly vendored rand code), we probably can remove it completely or move into a separate crate.

[dhardy]

Do we want this? I'm still not convinced.

If we do:

• The thread-rng name is not consistent with rand_core etc. Probably should be rand_thread_rng.
• We switched to using explicit features (Use explicit features rather than implicit. #1473)
• rand::rng, rand::random etc. need their cfg updated

[newpavlov]

Probably should be rand_thread_rng

How about rand_trng?

[newpavlov]

This PR is mostly ready for review. I will work on docs and readme after it's decided that we will move forward with it.

Do we want this?

I do. :) My main motivation is to be able to use and recommend rand's ThreadRng for uses in cryptographic applications.

[dhardy]

My main motivation is to be able to use and recommend rand's ThreadRng for uses in cryptographic applications.

You can already. And if you're talking about the disclaimer, it applies to this just as much as it does to rand.

[newpavlov]

I can not fully recommend it now because it pulls the whole rand, which is not a small dependency. Everything else except ThreadRng does not have any uses in this context as was mentioned in #1514.