Add host/device compatible RNG

[whokion]

Make RngEngine work on both host and device. This PR addresses and replaces the issue #19.
After merged, need to add options to use other generators/random states such as
MRG32k3a/curandStateMRG32k3a_t, Random123/curandStatePhilox4_32_10_t and etc, which
should work out of box. Also, generalize RngEngine.test.cu which currently works only for curandStateXORWOW.

[sethrj]

Two minor comments, and please add a very small unit test (as simple as just another TEST( inside of RngEngine.test.cu) showing that the initialization and sampling works for the RNG and generate_canonical functions. Thanks!

[sethrj]

This is a memory leak. For consistency with the other host tests, I suggest making a local RngState host_rng_state; and passing it in.

[whokion]

Changed accordingly.

[sethrj]

@whokion Aside from the single comment, there are two minor metadata-type changes:

1. The RngEngine test isn't formatted properly with clang-format. If you have clang-format installed, there's a script at scripts/dev/install-commit-hooks.sh that will install a git hook to auto-format it. Once that's installed, you can rebase interactively on master and it should auto-apply formatting to your commits.
2. Very minor comment but for consistency it would be good to captialize the first letter of commit messages 😅

If you don't have clang-format installet, let me know and I can help reformat the commits.

[whokion]

Tried to apply the clang-format. Please confirm.

[sethrj]

@whokion Something's still off... I'll just reformat on my end.

By the way, what's the advantage of the

CELER_FUNCTION RngEngine(RngState *state) : state_(*state) {}

constructor? Is that only defined for the host unit test?

[whokion]

Yes, the constructor is for the purpose of tests (for now), but may be served as a generic constructor used for both host and device depending on how RngEngine is instantiated. The current approach which is binding
a set of pre-initialized states (along with tid) and RngEngine itself is a bit less flexible if we really want to
use codes for both host and device as initialization APIs may be different between host (for either sequential or multithreading workflow) and device SIMT execution. We may revisit this discussion later, but I do not see any
downside to have this constructor either.

[sethrj]

That's fair, but I'd prefer to keep the view construction homogenous (even across potential future architectures) and minimizing the code base (at the expense of adding one extra line to the CPU-only unit test). The downside to having the raw pointer constructor is making the interface more complex and easy to accidentally misuse (there's a missing explicit for the construct-from-pointer).

I've clang-formatted the files, removed the raw-pointer constructor, and squashed the commits into a new branch sethrj/crng -- if those look ok, could you git reset --hard sethrj/crng and git push -f to update your branch to match?

[whokion]

Okay. Fine with me. I will consolidate your update and push the branch again.