Implements a numpy RNG which takes advantage of the many functions of numpy's RNGs as an alternative to Crow's RNG

[j-bryan]

---

Pull Request Description

What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)

2204

What are the significant changes in functionality due to this change request?

This is an alternative approach to resolving issue #2204 (see pull request #2205 for the other approach). In this approach, the existing implementation of the numpy stochastic environment which used numpy.random.RandomState is updated to using the numpy.random.Generator class. This Generator class provides additional control over the random numbers generated, such as specifying data types. Being able to specify a 32-bit data type for random numbers avoids an issue of RandomState consuming 2 random states from the underlying 32-bit MT19337 Mersenne Twister bit generator object to produce 64-bit random numbers. The Generator class also allows for use of other bit generators, should this flexibility be needed in the future.

This PR is left as [WIP] because the numpy RNG will cause many many failing tests.

---

For Change Control Board: Change Request Review

The following review must be completed by an authorized member of the Change Control Board.

• [ ] 1. Review all computer code.
• [ ] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
• [ ] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
• [ ] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
• [ ] 5. If significant functionality is added, there must be tests added to check this. Tests should cover all possible options. Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in XML block, the node <internalParallel> to True.
• [ ] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change. The requirements and the requirements test shall be in sync.
• [ ] 7. The merge request must reference an issue. If the issue is closed, the issue close checklist shall be done.
• [ ] 8. If an analytic test is changed/added is the the analytic documentation updated/added?
• [ ] 9. If any test used as a basis for documentation examples (currently found in raven/tests/framework/user_guide and raven/docs/workshop) have been changed, the associated documentation must be reviewed and assured the text matches the example.

[j-bryan]

Closing due to being made redundant by pull request #2205. The approach proposed by this pull request causes more than 400 of the existing integration tests (about 50%) fail by changing the random number generator output. It was deemed impractical to revise that many tests for a change with little meaningful impact in the operation of random number generation and distribution sampling.