[FEA] Changes to mdarray & mdspan to support future CPU paths

The following tasks should bring us closer to being able to support CPU code paths in cuML, though these changes should be useful to users in general:

• Ability to build against mdarray and mdspan headers without CUDA. I'm assuming once we have some CPU-enabled primitives within RAFT then this could also apply to those headers. The way this is achieved in Triton currently is through a preprocessor variable.
• We should remove the requirement that raft functions accept explicit accessor policies directly. Instead, they should just accept mdspan itself.
• Add support for tree-style layout indexing patterns, in addition to other potential layouts.
• Owning facility that can better unify the allocation and indexing of host and device memory.

The goal is to have the mdspan itself not necessarily care about the fact that the memory underneath is device, host, pinned host, or managed (or even registers or shared memory) and to have the underlying owning structure / accessor handle the requests accordingly.

One use-case we have for FAISS integration, for example, is being given a large chunk of CPU memory as input and moving only smaller chunks or slices to the GPU. This would require the accessor of mdspan and the container policy / allocator of the underlying mdarray to be smart enough to know that gpu memory is desired, and to create a new allocation on the GPU and copy from the CPU. I'm not sure if this is something a submdspan alone would be able to handle?

@trivialfis and @wphicks have both suggested wrapping the mdarray in a more unified owning object which could then produce an mdspan. It seems like this might ultimately be the way to go, but I think there's still some details to iron out, such as the example above.

Start by reviewing the mdarray and mdspan headers, their accessor policies, and the existing allocation or ownership paths. The issue lists several possible directions; completion would require an agreed design covering non-CUDA builds, alternate layouts, and unified host/device ownership and transfers.