Separating mdspan/mdarray infra into host_* and device_* variants

[cjnolet]

This is a breaking change as it provides users with a more granular set of headers to import host separately from device and managed versions. It also separates the headers for mdspan and mdarray.

As an example, the following public headers can now be imported individually:

raft/core/host_mdspan.hpp
raft/core/device_mdspan.hpp

raft/core/host_mdarray.hpp
raft/core/device_mdarray.hpp

cc @rg20 @afender @akifcorduk for awareness.

Closes #806

[divyegala]

Just a question about .cuh vs .hpp file extensions, and whether device_ files should be .cuh?

[cjnolet]

@divyegala I'm on the fence about whether the device_md{span|array} files should be in cuh files. On one hand, the default_accessor for the reference mdspan has a __device__ function but it's still in an hpp file. I think so long as the __device__ functions are kept trivial (like just for data loading), i'm inclined to keep the files as hpp for consistency. We should also be using a macro that can properly disable the __device__ in the event the compiler is not NVCC.

But, for example, if we start supplying more complex __device__ primitives that actually perform complex computations on device, or that directly use device intrinsics, I'd say we should opt to put those in files with the cuh extension (such as in mdspan_util.cuh.

[mhoemmen]

Please note that is_exhaustive() only means that the storage is contiguous. The range of the layout mapping need not necessarily be monotonically increasing (it could be backwards, for example).

[cjnolet]

Can you provide an example of your suggested way to force this to be row or col major? (Ideally we could do this at compile time).

[mhoemmen]

Here's a way to check if an mdspan is row or column major.

template<class ElementType, class Extents, class Layout, class Accessor>
constexpr bool is_row_or_column_major(mdspan<ElementType, Extents, Layout, Accessor> /* m */ )
{
  return false;
}

template<class ElementType, class Extents, class Accessor>
constexpr bool is_row_or_column_major(mdspan<ElementType, Extents, layout_left, Accessor> /* m */ )
{
  return true;
}

template<class ElementType, class Extents, class Accessor>
constexpr bool is_row_or_column_major(mdspan<ElementType, Extents, layout_right, Accessor> /* m */ )
{
  return true;
}

template<class ElementType, class Extents, class Accessor>
constexpr bool is_row_or_column_major(mdspan<ElementType, Extents, layout_stride, Accessor> m)
{
  return m.is_exhaustive();
}

(Relevant issue that you posted; thank you! #819 )

[cjnolet]

@mhoemmen, thank you for this thorough review! I've implemented most of your suggestions. I wasn't able to get this suggestion or this suggestion building, though most of the changes in this PR are just moving stuff around so I think we can continue to make things more clean and correct in follow-on PRs before release 22.10 is ready. Would you be interested in opening a PR w/ those changes?

[cjnolet]

rerun tests

[wphicks]

Love this! Had two questions on details, but this is a huge step forward for making use of mdspan in the FIL backend. I was not able to absolutely confirm that there were no gotchas with the CPU-only compilation, but everything looks good as best I can tell without finishing a version of the FIL code that makes use of this.

[cjnolet]

@gpucibot merge