Decide whether generated bindings replace the hand-written suite parser

[juherr]

Part of #3317, and deliberately the last step. This is a decision, not a task: it should be taken with the earlier steps done, not instead of them.

Where this comes from

#3240 added a testng-jaxb module: an XSD run through xjc, plus hand-written mappers to XmlSuite, registered through META-INF/services. It is still open and still mergeable, but it is a prototype:

• No tests at all. All three commits are authored by an AI agent; the author's own comment says "I will add tests soon".
• The XSD is a raw Trang dump of the DTD. Attributes are untyped, so xjc generates String everywhere and every mapper does Integer.parseInt / Boolean.parseBoolean by hand. xs:choice maxOccurs="unbounded" yields a single heterogeneous List<Object>, hence a chain of instanceof in SuiteMapper.
• TestMapper does not map <classes> — there is no ClassesMapper in the module at all — nor <packages>, <groups>, <method-selectors>, parallel, thread-count, time-out, enabled. It cannot produce a runnable suite.
• jaxb-runtime is not declared, only the API, so JAXBContext.newInstance would fail at runtime.
• The module is not part of the shaded org.testng:testng jar, so nothing reaches users today.

The design hazard to avoid

JaxbParser.accept() returns fileName.endsWith(".xml"), and Parser.getParser() consults ServiceLoader implementations before DEFAULT_FILE_PARSER. Putting the jar on the classpath therefore silently replaces the reference parser for every suite file, with no opt-in and no way to notice. Any alternative parser must be explicitly opted into.

What the decision hinges on

The boilerplate a binding framework removes is the SAX handler; the semantics it does not remove live in the mapping layer: ${...} expansion, defaults inheriting from suite to test, index assignment, <suite-files> resolution and relative paths, class loading under loadClasses, last-wins on duplicate parameters, deprecation warnings. #3240 is the evidence — 8 mappers and still no <classes>. Weighed against a hard public API with no binary compatibility gate in CI and an extra runtime dependency for a deliberately dependency-light project.

Note also that a binding layer does not remove the entity resolver (#3316): existing suite files carry <!DOCTYPE suite SYSTEM "https://testng.org/testng-1.1.dtd">, and any XML reader resolves that unless external DTD loading is disabled — which cannot be done blindly, since suite files may use external entities.

Ground rules if it goes ahead

• Opt-in only. Never accept(".xml") through ServiceLoader shadowing the default parser.
• Must pass the round trip corpus from fix(xml): re-enable DTD validation and stop losing data in toXml() #3315 — the serialized form a fixed point, and the parsed model identical through SuiteDigest.
• Ships as an optional feature variant, like snakeyaml, with its runtime dependency actually declared.
• Generated from the curated schema of Ship an XSD for testng.xml alongside the DTD, and keep the two from drifting #3319, not from a Trang dump.

Outcome

Either a plan that satisfies the above, or #3240 is closed with this reasoning recorded so the next attempt starts from it rather than from scratch a third time.