[Review][Java] Extend Dataset to work as an output data container

[ldematte]

In #902 and #1034 we introduced a Dataset interface to support on-heap and off-heap ("native") memory seamlessly as inputs for cagra and bruteforce index building.

As we expand the functionality of cuvs-java, we realized we have similar needs for outputs (see e.g. #1105 / #1102 or #1104).

This PR extends Dataset to support being used as an output, wrapping native (off-heap) memory in a convenient and efficient way, and providing common utilities to transform back and forth on-heap memory.
This work is inspired by the existing raft mdspan and DLTensor data structures, but tailored to our needs (2d only, just 3 data types, etc.). The PR keeps the current implementation simple and minimal on purpose, but structured in a way that is simple to extend.

By itself, the PR is just a refactoring to extend the Dataset implementation and reorganize the implementation classes; its real usefulness will be in using it in the PRs mentioned above (in fact, this PR has been extracted from #1105).
The implementation class hierarchy is implemented with future extensions in mind: atm we have one HostMemoryDatasetImpl, but we are already thinking to have a corresponding DeviceMemoryDatasetImpl that will wrap and mange (views) on GPU memory to avoid (in some cases) extra copies of data from GPU memory to CPU memory only to process them or forward them to another algorithm (e.g quantization followed by indexing).

Future work will also include add support/refactoring to allocate and manage GPU memory and DLTensors (e.g. working better with/refactoring prepareTensor).

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[ldematte]

As @chatman pointed out in #1105, this needs a better name, as it would not be a "Dataset" neither a "Graph" in the lexicon of cuvs.
@mythrocks what about CuVSMatrix or CuVSArray2d?

[cjnolet]

Linking cjnolet/nv_elastic#22

[mythrocks]

@mythrocks what about CuVSMatrix or CuVSArray2d?

Sorry for the delay. (It has been a packed day, today.) I like the idea of calling this the CuVSMatrix. 👍

There might be value in differentiating whether the matrix is in __host__ or __device__ memory. Separate types: CuVSDeviceMatrix vs CuVSHostMatrix?

[cjnolet]

There might be value in differentiating whether the matrix is in host or device memory. Separate types: CuVSDeviceMatrix vs CuVSHostMatrix?

+1 for this. We do this in all of our other APIs (python, c++) and it really helps us keep them clean and relatively self-documenting

[ldematte]

I like the idea of separate types, I was already planning to do this at implementation level (e.g. HostMemoryDatasetImpl). I can have intermediate CPU/GPU interfaces, but I'd like to keep a common ancestor. So we'll have CuVSMatrix, which can be either, and sub-interfaces CuVSDeviceMatrix and CuVSHostMatrix.
Why the common type? So when we want, we can be specific. When we don't want to be specific, we can pass the more generic type to any cuvs function and choose the path to take "dynamically" like we do like in the C API: if (isGPU(matrix)) then do() else copyToGPUMemory(); do(); (very pseudo).

WDYT?