Introduce jvector-apis module and status tracker

[jshook]

[Updates 10/15]:

With some first-user input from Mark and some other cleanups and improved docs, the core code is tighter, safer, and cleaner. There were several files added in test, specifically to make it easy to understand the usage patterns for implementing tracked tasks.

I believe that we should have living examples where we can, and that means they should be tested. If necessary, we can put a group tag on the "example" tests to bypass them conveniently except for release-level tests. For now, they are enabled for review here.

[Previously ...]

The status tracking module may have use in both prod and test code, but we wanted to isolate and manage it better as a separate module. For modules like this, I propose we use a jvector-apis module. This is where you would put new modular functionality, like the status tracking API, which may be used by multiple modules. There is a good primer on this in the README in the module root.

For the status tracking API, this is a new facility to allow us to collect and share the status of internal jobs that are being run by jvector. The first use of it will be to ease testing and baseline work around performance and accuracy for different vector spaces and indexing configurations. However, it does have some hooks which may be lightweight enough to instrument prod code with, and this is a separate concern not addressed specifically in this PR. For now, this merely introduces the status tracking API, which will be pulled into the dataset streaming work once when ready.

There is a substantial amount of testing included in this PR. The demo scaffolding is there as a test layer for improving the API and making sure it is ergonomic and non-invasive enough to be added to extant code. If necessary, we can gate the unit tests of this module with an optional test group, but I'd like to see how it works as is first.

There are a couple of unrelated cleanups in this PR as well, from previous commits by other committers, around mvn exec configs, logger and test dependency inclusions which were not intended. I've personally contacted these committers and verified their intent before removing the extra deps and configurations.

[github-actions]

Before you submit for review:

• Does your PR follow guidelines from CONTRIBUTIONS.md?
• Did you summarize what this PR does clearly and concisely?
• Did you include performance data for changes which may be performance impacting?
• Did you include useful docs for any user-facing changes or features?
• Did you include useful javadocs for developer oriented changes, explaining new concepts or key changes?
• Did you trigger and review regression testing results against the base branch via Run Bench Main?
• Did you adhere to the code formatting guidelines (TBD)
• Did you group your changes for easy review, providing meaningful descriptions for each commit?
• Did you ensure that all files contain the correct copyright header?

If you did not complete any of these, then please explain below.

[MarkWolters]

Great documentation, that is appreciated. Commented a few minor concerns but overall looks very strong

[MarkWolters]

why remove this plugin?

[jshook]

This was added before by a dev that I follow up with before removing it. This wasn't removing the plugin entirely, but it was removing a default that was affecting all invocations of the exec plugin which didn't have their own local overrides. Specifically it was skipping execution, and that seemed to have an undesired side-effect on sub-modules as well.

[MarkWolters]

I think this looks good. The documentation and the example code really helps.