Raise Java baseline to 17 and clean XML parsers for JDK 22+

[dyrpsf]

This PR raises the Java baseline to 17 and removes legacy XML parser dependencies so SBSCL
runs cleanly on modern JDKs (tested locally on JDK 24).

Changes:

• Set jdk.version to 17 and updated maven-compiler-plugin to 3.11.0 with <release>17</release>.
• Excluded xercesImpl, xml-apis, and xalan from the jlibsedml dependency so that the
  built-in JDK JAXP stack is used. This avoids the AbstractMethodError seen on JDK 22+ when
  legacy XML parsers shadow the JDK implementation.
• Verified mvn test succeeds on a Java 17+ JDK (24 in my case); FBA code under
  org.simulator.fba compiles and is usable with the new baseline.
• Updated README, INSTALL, and UserGuidelines to state that Java 17+ is required.
• Updated .travis.yml to run the CI matrix on OpenJDK 17 and a newer OpenJDK version
  instead of Java 11.
  issue Raise Java baseline & ensure FBA runs cleanly on Java 22 (deprecate Java 8) #91

[xts-Michi]

As mentioned in another PR, I am currently testing and debugging the full implementation of OptSolvX as a new backend for SBSCL (see #90 for current status).

Consequently, this PR should remain on hold until the OptSolvX implementation is complete. This ensures the new Java baseline and XML parser can be tested in the anticipated environment. Raising those versions now would interfere with current progress and create unnecessary overhead.

[dyrpsf]

As mentioned in another PR, I am currently testing and debugging the full implementation of OptSolvX as a new backend for SBSCL (see #90 for current status).

Consequently, this PR should remain on hold until the OptSolvX implementation is complete. This ensures the new Java baseline and XML parser can be tested in the anticipated environment. Raising those versions now would interfere with current progress and create unnecessary overhead.

Thanks a lot for the explanation and the pointer to PR #90!

That makes sense—raising the Java baseline and adjusting the XML parser stack while the
OptSolvX backend is still being developed could easily interfere with your current work.

I’m happy to keep this PR on hold until the OptSolvX implementation is complete and the
new Java 17+ / JAXP setup can be tested in the final environment. Once PR #90 is merged or
the integration is otherwise ready, please let me know and I’ll gladly rebase this branch
on the updated master and make any adjustments needed so that the Java 17 / XML changes
fit cleanly into the new setup.

[draeger]

I am in favor of this change in principle, but always a bit hesitant to introduce higher requirements because some users or developers might not be able to update their Java version (for many reasons). However, Java 17 was released in late 2021, so it has been around for nearly half a decade. For this reason, I can support this step.

[dyrpsf]

I’ve pushed a small follow-up commit to address the review comment on the README.

• Updated the “Requirements” section to add the missing comma after “e.g.” (e.g., JDK 22+).

mvn -DskipTests compile still completes successfully.
Please let me know if you’d like any further adjustments to the wording or Java version notes.

[draeger]

Thanks!

[NeumannArthur]

I agree with @draeger, since it has been nearly 5 years it should be safe to upgrade to Java 17 from a user perspective.
I approve these changes, however I would also recommend merging and closing PR #90 first in order to avoid conflicts with @xts-Michi's work on OptSolvX, as there appear to still be some branch conflicts. This avoids any unexpected behaviour.