cuvs-java: Rework the api to be Java 21 friendly

[ChrisHegarty]

This change reworks the api to allow it to be used with Java 21. The implementation is moved to an internal package, compiled with JDK 22, and packaged as an mrjar. The benefit of this structure is that the api can be used in environments that compile to a minimum of Java 21, but run on more recent JDKs like 22 and 23 - which is exactly what Elasticsearch and Lucene do. In fact, a minimum compilation target of Java 21 is common, since 21, at the time of writing, is the most recent LTS Java release.

The most significant change is that the non-trivial api types are now, for the most part, interfaces. Instance can be created by one of the factory methods, which lookup an spi to find the implementation. If on a release greater than Java 21, then a functioning implementation is returned. Otherwise, a no-op implementation is returned. This is a reasonably standard way for a Java api to behave, and allows the developer to handle the case where the platform does not have a functioning implementation.

This change also refactors the native downcall method handles so that they are static final constants - which optimise better by the JVM. It's also the generally accepted pattern, where the handles are tied to the lifetime of class which effectively mediates access - by virtue of reachability.

Another thing that I added is the ability to programmatically set the temporary directory used for intermediate operations - this is important to how both Lucene and Elasticsearch work - since they commonly only have permission to write to certain parts of the disk.

Additionally,

1. the error codes from native calls are plumbed in and checked. As well as cuvsGetLastErrorText.
2. a state is added to any classes that hold a reference to native resources that could be released.
3. a local arena is used for memory allocation only needed per downcall invocation, e.g. the return value.
4. I moved the tests to be integration tests, since they need to run on the jar (rather than the exploded classes). They can be run by any of; mvn verify, or mvn integration-test, or mvn -Dit.test="*Hnsw*" verify
5. I refactored the entry-points to the api to be static methods and added an spi layer. You can see the minimal impact on the tests.
6. Move the native library out of the top-level directory in the jar and into an os/arch position in the META-INF.
7. add service provider support for custom implementations.

[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.

[cjnolet]

/ok to test

[cjnolet]

/ok to test

[cjnolet]

/ok to test