mirage-crypto-rng-mirage: provide a module type S (to overcome the mirage-random opam package)

[hannesm]

The idea is to not be complete (otherwise, we could make Mirage_crypto_rng a module type), but to focus on the useful and used functions, which are:

• generate/generate_into -- needless to say
• entropy sources discovery -- so a unikernel can figure out what their sources are
• registering a new source and feeding data (so, in case you have a hardware RNG (see e.g. nethsm or qubes-random-seed or whatever, you'd like to add that to the mix)

If there are any remaining functions that are used in the wild, please let me know. I also ensured to provide type equality, thus the full Mirage_crypto_rng can be used. Let me know what you think of it. I tested it locally with the unikernel example and a hardcoded new entropy source.

[hannesm]

I've to admit that I'm a bit uncertain - the context being https://github.com/mirage/mirage/issues/1513 I guess the whole "(R : Mirage_random.S)" or now "(R : Mirage_crypto_rng_mirage.S)" (or "(R : module type of Mirage_crypto_rng)") will vanish, the question is what do we want in the intermediate:

• Mirage_crypto_rng.S (👍🏾)
• module type of Mirage_crypto_rng (🎉)
• Mirage_crypto_rng_mirage.S (❤️)
• module type of Mirage_crypto_rng_mirage.Make (_)(_) (I guess this is not (easily) expressible

I'm fine with the ❤️, which is what this PR proposes. The reasoning is that once we have 1513 in place, we only need to very locally remove the module type S (in mirage-crypto-rng-mirage), and move on.