serde for BlockRng, ReseedingRng and ReadRng

[dhardy]

Closes #1101, which also discussed serde for other RNGs.

• implements for ReadRng: probably useless?
• implements for ReseedingRng: probably useless since the reseeder will normally be a non-deterministic RNG
• corrects bounds for BlockRng: required for ReseedingRng and I guess was never picked up in previous tests?
• rand/serde1 now requires rand_core/serde1, required for ReseedingRng and probably sensible
• does not implement for OsRng: useless, and easy to skip as a field in structs
• does not implement for StdRng or SmallRng: as @kazcw points out, non-stable serialisation would be a pit-fall
• does not implement for Hc128Rng: would require https://crates.io/crates/serde-big-array or some workaround until some future MSRV bump but I doubt anyone cares anyway

I'm tempted to remove the ReadRng and possibly ReseedingRng support but there doesn't seem a good reason either way. Thoughts?

[vks]

I don't have an opinion on ReadRng, because I don't know what it is used for. If it is used on files, serialization makes sense, but why would anyone do that? For /dev/urandom, serialization does not make sense, but I don't see a point of doing this over using OsRng. To be honest, I don't see a convincing use case for ReadRng and would be tempted to deprecate it.

I think ReseedingRng almost always makes the RNG non-deterministic, so I don't think serialization makes sense?

I agree that the implementation for BlockRng should be added.

[dhardy]

I think ReadRng is just a left-over component of the old OsRng. I couldn't find any actual usage. It's now deprecated as suggested.

Review?

[vks]

Looks great! Maybe you could also update the changelog?

[dhardy]

I'll get to the changelog later. Once current PRs are merged I think we should do the next patch release (don't think there's any breaking changes).