Skip jextract binding generation by default

[ashkrisk]

Description

Modify the process by which maven builds the native SIMD library so that bindings are not generated by default.

Motivation

The existing build process re-generates the bindings on each build as long as jextract is in the path. This can cause issues since the jextract version on the system may not match the jextract version used to generate the checked-in bindings. This not only creates noise in the git working tree, but can also cause build errors since newer jextract releases may use language features from newer JDKs.

Changes made:

• Split the jextract_vector_simd.sh script into two scripts, one which builds the native library and the other which generates bindings using jextract.
• The binding generation script is added to the pom, but is skipped by default.
• Warn if the jextract version found doesn't match the expected jextract version.
• In case multiple versions of jextract are present on the system, you can specify which one to use via an environment variable.

Additional information

The attached release notes describe the expected usage pattern.

Example of the kind of error that I observed on my system which had jextract 25 installed:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile (default-compile) on project jvector-native: Compilation failure: Compilation failure: 
[ERROR] /path/tojvector/jvector-native/src/main/java/io/github/jbellis/jvector/vector/cnative/NativeSimdOps.java:[1135,63] cannot find symbol
[ERROR]   symbol:   method findOrThrow(java.lang.String)
[ERROR]   location: variable SYMBOL_LOOKUP of type java.lang.foreign.SymbolLookup
(... more instances of the same error)

[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 rebase your branch onto the latest main for regression testing and PR submission?
• Did you trigger regression testing via Run Bench Main and review results?
• 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?
• Did you add documentation for this feature to the release notes directory?

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