Using raft::resources across raft::random

[cjnolet]

Eventually we need to do this across all the headers in the codebase so that users have a choice as to whether they want to use raft::device_resources (which implicitly depends on the cuda math libs and thrust) or whether they just want to use raft::resources (which is agnostic of the resources it contains and allows the primitives themselves to levvy the dependency requirements).

cc @MatthiasKohl this should allow cugraph-ops to completely remove the math libs dependency (though the conda recipes will also need to be changed to depend on libraft-headers-only and the cmake changed to turn off the CTK math libs dependency).

NOTE: Before this PR is merged, it's important that it be tested w/ cugraph/cuml at the very least to spot any cases where the device_resources.hpp include was being assumed transitively from the RAFT functions.

[MatthiasKohl]

Thanks @cjnolet I'll try this out soon in cugraph-ops.
Do you have a small guide on how to move from the actual implementations (in detail) to these higher-level APIs with the handle and the views?
Also, will the pointer-based APIs be deprecated (they aren't yet in rng.cuh)?

[benfred]

lgtm!

[cjnolet]

Also, will the pointer-based APIs be deprecated (they aren't yet in rng.cuh)?

I'll make sure I give a good heads up when these are finally removed. It's hard to explicitly deprecate everything individually but the general state of RAFT is that we're shifting the public APIs to the mdspan-based variants and raft::resources. It shouldn't be too complicated to shift over to the new APIs- mdspan is just a lightweight wrapper around a pointer w/ some shape information.

I might submit a PR to cugraph-ops to attempt this change.

[cjnolet]

/merge