Remove unused JAXB annotation support from rewrite-maven

[timtebeek]

• Fixes Refactor JAXB out #8669

rewrite-maven depended on com.fasterxml.jackson.module:jackson-module-jaxb-annotations and the pre-Jakarta javax.xml.bind annotations. As suspected in the issue, all of it was dead weight:

• JaxbAnnotationModule was only registered on MavenXmlMapper.writeMapper().
• The only JAXB-annotated classes, RawPom and RawGradleModule, carried @XmlRootElement(name = "project") but are exclusively deserialized — RawPom through readMapper() (which never had the module) and RawGradleModule through propertyBasedMapper (a JSON mapper, so the XML root name was inert there regardless).
• Everything that actually goes through writeMapper() already uses Jackson's native XML annotations: MavenSettings (@JacksonXmlRootElement(localName = "settings")), AddDevelocityMavenExtension's config classes (@JacksonXmlRootElement), and Plugin.getConfiguration(path, Class) which just round-trips a JsonNode.

So this drops the dependency, the module registration, and the two annotations.

Verified with MavenSettingsTest (which asserts the exact serialized XML round-trips to the parsed document), AddDevelocityMavenExtensionTest, and RawPomTest (which covers the writeMapper path in Plugin.getConfiguration). The three failures in that local run were all Maven Central HTTP 429s, unrelated to the change.

[timtebeek]

No rush on getting this through @knutwannheden , but I figured you'd be the best judge of effects on (de)serialization. Seemed OK with a small caveat on the dropped transitive dependency & automatically registered modules.

[timtebeek]

One caveat worth recording, since it isn't visible in the diff: rewrite-maven was the only declaration of jackson-module-jaxb-annotations anywhere in the ecosystem, so that jar and its jaxb-api transitive drop off every consumer classpath that was getting them for free — including the Moderne CLI, where both are on the classpath today purely via this dependency.

I checked that nothing else needs them. Scanning the CLI 4.6.3 distribution (its own classes plus all 296 bundled jars), the only classes referencing javax.xml.bind or com.fasterxml.jackson.module.jaxb are the three rewrite-maven internals this PR changes.

Two follow-on notes:

• jackson-module-jaxb-annotations self-registers via META-INF/services/com.fasterxml.jackson.databind.Module, so any Jackson mapper built with findAndRegisterModules() picks up JaxbAnnotationModule implicitly today. That does happen on the CLI's v3 marker path. I measured it before/after on an unpatched build (so @XmlRootElement still present) and marker-table and whole-LST bytes are identical with and without the module — unsurprising, since every JaxbAnnotationIntrospector hook is annotation-gated and there are no JAXB annotations left to act on. The CLI's v2 serializer registers its modules explicitly, so it never saw the module at all.
• The one arrangement that would break is a mixed-version classpath: pre-8.9x MavenXmlMapper classes loaded against a resolution that has already dropped the jar would hit NoClassDefFoundError: com/fasterxml/jackson/module/jaxb/JaxbAnnotationModule. Normal resolution keeps those in lockstep — the POM declaring the dependency is the one carrying the calling class — so this only matters for anything that pins jars individually.