Extend RNG options to three, addressing issue #348

[daniel-klein]

Renames and extends the multirng option in settings, now called 'rng'.

Set how random numbers are handled in Starsim with three options:

• "centralized" uses the centralized numpy random number generator for all distributions.
• "single" uses a separate (SingleRNG) random number generator for each distribution.
• "multi" uses a separate (MultiRNG) random number generator for each distribution.

"single" is the default value for this option.

In comparing two simulations, the "single" option may be slightly better than the "centralized" option without any real disadvantages. Only "multi" can achieve full common random number (CRN) coherence, but is more computationally expensive and only produces CRN results when using CRN-safe code.

In practice, devtest_rng.py shows that multi > single > centralized, but that single and centralized have nearly identical performance. So this PR switches the default to single, which uses the SingleRNG under the hood to track seeds for each stream.

Closes #348

[cliffckerr]

This works, but I'm not sure why we would want to give users one good option (multi-RNG) and two bad options (single and centralized)? I could imagine someone using single instead of multi if they only care about performance and their own code isn't RNG-safe, but I don't know why someone would want centralized instead of single.

Suggest we consider this together with #351 (once it's ready) and decide how to proceed.

From benchmark_full.py, I got:

'centralized': 3451 ± 19 ms
'single':      3362 ± 13 ms
'multi':       4851 ± 37 ms

[daniel-klein]

Unclear to me if most users will want 'single' or 'multi'. We currently only have one network (EmbeddingNet) and a few diseases that are CRN safe. It makes sense to run 'multi' for these, depending on the application, but otherwise users will use the default 'single' option.

I do want to keep 'centralized' around, e.g. to create figures for the CRN paper. But it can be obscure (sorta already is?) and likely removed at a later time.

[daniel-klein]

What do you think about the names?

I like 'centralized', that's clear as to what's going on. But 'single' vs 'multi' is a misnomer considering both establish one random number generator instance per distribution. Single could be 'per-distribution' or even 'multi'? And what's currently 'multi' could become 'CRN'? Thoughts?

[daniel-klein]

Of course, if we rename 'multi', I would also change the name of the 'MultiRNG' and we'd have to fix all the 'options.multirng' calls, but that's doable. And 'SingleRNG' could stand to be renamed as part of that as well.

[cliffckerr]

Ok, we can merge for now and refactor later. I agree the names aren't perfect, but would suggest holding off on a refactor until we decide on the long-term path forward.

[cliffckerr]

Almost the entirety of SingleRNG's code is duplicated in MultiRNG:

To reduce code duplication, could SingleRNG be the base class and then MultiRNG derive from it?

[cliffckerr]

Let's merge this and then compare with refactor-rngs.

[cliffckerr]

Looks good, will merge for now