The future of `ThreadRng`

Can we have one generator to do it all (excepting reproducibility)? ThreadRng attempts to achieve this:

• It's fairly fast
• It only requires 320 bytes + overhead (Rc and thread_local) per thread
• It's unpredictable
• It has periodic reseeding

Put another way, there are reasons that this is sub-optimal:

• SmallRng is significantly faster (very roughly double the performance) and much smaller (32 bytes) while being good enough for many uses
• ThreadRng does not currently have forward secrecy. We could tack this on for approx 10-25% performance overhead.

Plan

ThreadRng has quite a few users, so I do not believe we should just abandon it. Instead, I propose:

• Re-add ReseedingRng not as a generic wrapper but as a concrete struct over ChaCha12 with periodic reseeding and fast erasure.
• Add StrongRng (name?) as a handle to a Mutex<ReseedingRng> in static memory (feature-gated, default off).
• Add SmallThreadRng as a thread-local SmallRng and maybe rand::fast_rng() to access it (feature-gated, default off).
• If possible, #[deprecate] the existing ThreadRng and methods after adding replacements before the next breaking release.

Note: the fast-erasure (forward secrecy) addition requires breaking changes to rand_core. The rest should be possible to add in a patch release.

Note: this is very much a tentative plan. Feedback welcome!

Start by reviewing the existing ThreadRng and rand_core interfaces, then compare the proposed ReseedingRng over ChaCha12, StrongRng, and SmallThreadRng entry points. Done means the tentative replacement and deprecation plan is resolved and implemented, with the required forward-secrecy changes to rand_core accounted for.