Provide a raft::copy overload for mdspan-to-mdspan copies

[wphicks]

Purpose

This PR provides a utility for copying between generic mdspans. This includes between host and device, between mdspans of different layouts, and between mdspans of different (convertible) data types

API

raft::copy(raft_resources, dest_mdspan, src_mdspan);

Limitations

• Currently does not support copies between mdspans on two different GPUs
• Currently not performant for generic host-to-host copies (would be much easier to optimize with submdspan for padded layouts)
• Submdspan with padded layouts would also make it easier to improve perf of some device-to-device copies, though perf should already be quite good for most device-to-device copies.

Design

• Includes optional RAFT_DISABLE_CUDA build definition in order to use this utility in CUDA-free builds (important for use in the FIL backend for Triton)
• Includes a new raft::stream_view object which is a thin wrapper around rmm::stream_view. Its purpose is solely to provide a symbol that will be defined in CUDA-free builds and which will throw exceptions or log error messages if someone tries to use a CUDA stream in a CUDA-free build. This avoids a whole bunch of ifdefs that would otherwise infect the whole codebase.
• Uses (roughly in order of preference): cudaMemcpyAsync, std::copy, cublas, custom device kernel, custom host-to-host transfer logic for the underlying copy
• Provides two different headers: raft/core/copy.hpp and raft/core/copy.cuh. This is to accommodate the custom kernel necessary for handling completely generic device-to-device copies. See below for more details.

Details on the header split

For many instantiations, even those which involve the device, we do not require nvcc compilation. If, however, we determine at compilation time that we must use a custom kernel for the copy, then we must invoke nvcc. We do not wish to indicate that a public header file is a C++ header when it is a CUDA header or vice versa, so we split the definitions into separate hpp and cuh files, with all template instantiations requiring the custom kernel enable-if'd out of the hpp file.

Thus, the cuh header can be used for any mdspan-to-mdspan copy, but the hpp file will not compile for those specific instantiations that require a custom kernel. The recommended workflow is that if a cpp file requires an mdspan-to-mdspan copy, first try the hpp header. If that fails, the cpp file must be converted to a cu file, and the cuh header should be used. For source files that are already being compiled with nvcc (i.e. .cu files), the cuh header might as well be used and will not result in any additional compile time penalty.

Remaining tasks to leave WIP status

• Add benchmarks for copies
• Ensure that new function is correctly added to docs

Follow-up items

• Optimize host-to-host transfers using a cache-oblivious approach with SIMD-accelerated transposes for contiguous memory
• Test cache-oblivious device-to-device transfers and compare performance
• Provide transparent support for copies between devices.

Relationship to mdbuffer

This utility encapsulates a substantial chunk of the core logic required for the mdbuffer implementation. It is being split into its own PR both because it is useful on its own and because the mdbuffer work has been delayed by higher priority tasks.

Close #1779

[wphicks]

/ok to test

[wphicks]

/ok to test

[wphicks]

/ok to test

[wphicks]

CI failing for same reason as other 23.12 PRs. I believe this should be unblocked after #1868 goes through and gets merged back into this PR.

[cjnolet]

/ok to test

[cjnolet]

/merge