Update cirq.RANDOM_STATE_OR_SEED_LIKE to support np.random.Generator

[NoureldinYosri]

Is your feature request related to a use case or problem? Please describe.
We have several modules that spwan multiple threads for performance. each of those threads would be running a random operation using a random state or state. when those threads share the same RandomState the multithreading degenerate into sequential processing since those threads will be waiting on write operation of the random state.

Describe the solution you'd like
Start supproting np.random.Generator. This class provides the same API of np.random.RandomState in addition to a spawn function which can be used to create independent streams of random values. This will help when starting threads e.g.

   new_random_generators = prng.spwan(number_threads)
  with ThreadPoolExecutor(max_workers=2) as pool:
          # submit job i with prng new_random_generators[i]

Describe alternatives/workarounds you've considered
Before calling multithreads generate multipleseeds using a np.random or RandomState. While this seems like what we are doing with np.random.Generator.spawn; it's actually different in that the radom seeds and hence the random sequences created will correlate. This means that when running the same operation (e.g. simulation) multiple times in parallel, the results will correlate.

state_0 -> state_1 -> state_2 -> ...
  \         \          \         \
   v         v          v         v
   output_0 output_1   output_2  ....

Additional context (e.g. screenshots)
The cirq random number support is implemented in cirq-core/cirq/value/random_state.py

What is the urgency from your perspective for this issue? Is it blocking important work?
P2 - we should do it in the next couple of quarters

[mhucka]

There was a past issue involving np.random and multiprocessing. It may not be a concern with the present issue, but on the off chance that there are implications for this issue, it seemed worth pointing to it: #3717 ("Can't use cirq.Simulator() in a multiprocessing closure (unable to pickle)")