Turn netex-java-model into a JPMS module

[t2gran]

Summary

Turns netex-java-model into a proper JPMS module by adding a module-info.java
(org.entur.netex.java.model), replacing the Automatic-Module-Name manifest
entry that was there before. Also renames org.rutebanken.util to
org.rutebanken.netex.util for consistency with the other
org.rutebanken.netex.* packages.

This needs to land as 3.x — the package rename breaks anyone importing
org.rutebanken.util.* directly (the four XmlAdapter classes).

What's in module-info.java

• requires transitive on jakarta.xml.bind, java.xml, and
  org.apache.commons.lang3 — their types leak into our public API
  (JAXBException, QName/XMLGregorianCalendar on NeTExValidator, and
  OmitNullsToStringStyle extends ToStringStyle), so callers need readability
  to them too.
• The generated packages (org.rutebanken.netex.model, net.opengis.gml._3,
  uk.org.siri.siri) are opensed to jakarta.xml.bind,
  org.glassfish.jaxb.runtime, and org.apache.commons.lang3. XJC generates
  field-level JAXB access (@XmlAccessorType(FIELD)) and the generated
  toString() uses ReflectionToStringBuilder, both of which need reflective
  field access. All three targets were confirmed necessary by removing each
  one and rerunning mvn clean test until it broke — nothing here is a guess.
• mvn clean test is verifying the module-info.java - no other automatic
  tests/verification is needed.

Open questions for review

• Should exports/opens be narrowed further? Right now everything
  compiled from the schema is exported. net.opengis.gml._3 and
  uk.org.siri.siri have to stay exported (model getters return those types
  directly), but org.rutebanken.netex (just OmitNullsToStringStyle) and
  org.rutebanken.netex.util (the XmlAdapters) are only ever referenced
  from generated code in the same module — they may not need to be exported
  at all, possibly just opens ... to org.glassfish.jaxb.runtime for the
  adapters so JAXB can still instantiate them reflectively.
• PublicationDeliveryClient doesn't look like it belongs in a model
  library. It's a raw HttpURLConnection POST client with no timeouts,
  auth, or retry handling, and it's the only place that needs slf4j for its
  own sake (NeTExValidator uses slf4j regardless, so removing the client
  doesn't drop the dependency, just this one usage of it). Candidate for
  removal in this same 3.x bump, or split into a separate module — needs a
  decision before merge since it's a real API removal.
• Why is uk.org.siri.siri a dependency at all? It's not us pulling in
  something unrelated — NeTEx_siri.xsd is part of NeTEx's own official
  schema (bundled in the NeTEx repo we download from), and it's used by 7
  DataObject*/subscription-related classes for a SIRI-based real-time
  query/subscription API layer. Since XJC compiles transitively from
  NeTEx_publication.xsd, this gets generated whether or not any given
  consumer uses it.
• io.github.threeten-jaxb:threeten-jaxb-core should be inlined. Its
  DurationXmlAdapter is ~8 lines wrapping Duration.parse/.toString().
  Not worth a dependency (and its module) for that — copy it into
  org.rutebanken.netex.util alongside the other adapters and drop the
  dependency.

None of the four items above are implemented in this PR — flagging them here
for discussion before deciding what else goes into the 3.x bump.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud