Usability enhancements for external package authors

[rstub]

With PR #58 on its way it makes sense to think about how external users, in particular package authors, could make use of this:

• Users MUST NOT delete the RNG. In order to make this less likely one could offer a wrapper class as the official interface, c.f. feat: global RNG access #58 (comment). This wrapper should implement dqrng::random_64bit_generator which can be used together with C++ distribution functions since it supports UniformRandomBitGenerator. Note that in order to support the sampling methods this requires moving bit64() and bit32() from random_64bit_wrapper to random_64bit_generator as well as a change in the signature of these methods, i.e. the expected RNG should not come as dqrng::rng64_t.
• Users SHOULD NOT store a reference to the RNG permanently, because it can be invalidated by calls to dqRNGkind. This can be handled by documenting best practices.
• Some support for parallel usage patterns similar to https://daqana.github.io/dqrng/articles/parallel.html#xoroshiro-jump-ahead-with-openmp:
  • Instead of creating a new global RNG in serial code, one retrieves the global RNG from the package.
  • In parallel code, clone the RNG and switch stream, probably via something like dqrng::random_64bit_generator::clone(uint64_t stream). RNG specific implementations can be handled similarly to current stream specific template specializations. Note: I am not sure if one can implement this for the Threefry engine, as there is no way to increment the counter.

[rstub]

Part of this is already covered in #58. What is still needed:

• Signature change for sampling methods to accept external RNG.
• Support for parallel computation, e.g. via clone(stream) method
• Maybe extend documentation?

[hsloot]

Note that it was not necessary #58 to move bit64 and bit32 (but you could still do it if it makes sense to you).

[rstub]

It might also make sense to implement some of the random_generator interface suggested in https://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html.