Future of `block` module

The block module is designed to assist implementing Rng for a block-generator. #31 (and the linked PRs) brought up a number of issues with prior designs, some of which have been solved. Some remaining issues:

• The internal buffer prevents RNGs from simply deriving serde (or other serialization) support; methods have been added to make this possible but they are often harder to use.
• Fn Generator::drop exists to provide compatibility with zeroize; while functional the design is inelegant.
• There is a significant amount of code for few downstream use-cases.

To the latter point: the block module is currently used by the following crates:

• chacha20
• rand_chacha
• rand_hc
• rand_isaac

All of these have at some point been used to provide rand::rngs::StdRng. The latter two already have very few downloads on crates.io for the latest versions, indicating few (if any) direct users. chacha20 is value-compatible with rand_chacha. It may therefore be viable to deprecate all three of the latter crates.

It may therefore make sense to move the block code into chacha20 (and any other block RNG impl which doesn't get deprecated), possibly with one more addition to rand_core::utils to cover the fill_bytes implementation.

Start by reading this issue together with #31 and its linked pull requests, then inspect the block module and its uses in chacha20, rand_chacha, rand_hc, and rand_isaac. Done means producing and agreeing on a concrete direction for the module, including which crates remain supported or are deprecated and how serialization and zeroization concerns are handled.