chore: add CryptoRng trait bound

[alxiong]

References #116

Right now, we mostly use StdRng which already implements CryptoRng (even though not deterministic) or not as fast as ChaCha20Rng.

But this should be a first step towards CryptoRng trait bounds to relevant APIs.

[TalDerei]

looks good to me 👍

[ebfull]

If we're stuck using an old version of rand right now for some reason, then I don't want to bother with a refactoring like this. Otherwise, concept ACK from me.

[alxiong]

If we're stuck using an old version of rand right now for some reason,

pasta_curves shackle us to rand ^0.8 (where the latest stable rand is 0.9.3, and 0.10.0-rc.9 is also available)

[ebfull]

I've opened #437 to help us move in the right direction on rand, at the cost of some temporary dependency patches. I'll work with str4d to try to get these merged and released in their crates over the next month or two hopefully.

[ebfull]

This can be rebased on main to use rand 0.9 APIs instead.

[alxiong]

rebased. but we should still have Rng + CryptoRng (instead of either or) imo. Do you disagree?

[ebfull]

In rand 0.9, CryptoRng: RngCore and there is a blanket impl<R: RngCore + ?Sized> Rng for R. This means any CryptoRng automatically implements Rng, making Rng + CryptoRng redundant. The idiomatic bound is just CryptoRng.

Currently, I don't think we even call Rng extension methods. We just pass the rng into things like F::random (which take RngCore).