Make the YAML schema cover what a suite file can express

[juherr]

Part of #3317, fallout from #3318.

The YAML writer was rewritten in #3318 to emit only the keys the reader can bind, so that
parse -> toYaml -> parse is lossless. That made the gaps explicit: seven things a suite file can
carry have no YAML key at all, and the reader has two inconsistencies of its own.

This issue is the list. Closing it means the YAML schema covers what XML covers -- which is also
what #3321 needs before the binding contract can be written down honestly.

Values that cannot be read back

value	why	cost to close
XmlTest time-out	getTimeOut() returns String, the public setter takes long and the String one is private, so Introspector sees a read-only property	make setTimeOut(String) public -- one keyword, binary and source compatible (setTimeOut(0) still picks the long overload)
XmlInclude invocation numbers	the mutator is addInvocationNumbers, there is no setter	add setInvocationNumbers(List<Integer>) over the final Set -- purely additive. This is the most user-visible loss: converting testng-failed.xml silently drops the failed-invocation selection
suite level group-by-instances	getGroupByInstances() returns Boolean, setGroupByInstances(boolean) takes a primitive, so Introspector drops the write method	needs a Boolean overload, which changes overload resolution for setGroupByInstances(Boolean) -- today it unboxes and NPEs on null, after it would store null. Weigh it against the absence of binary-compatibility tooling in CI
object-factory	writable in Java, but the stock snakeyaml Constructor cannot build a java.lang.Class from a scalar	a Construct for Class in TestNGConstructor -- a reader change
use-global-thread-pool	useGlobalThreadPool() / shouldUseGlobalThreadPool(boolean) are not JavaBean accessors, so it is not a property in either direction	renaming them is a bigger API decision than this issue
suite level <define>	XmlSuite has no metaGroups property, unlike XmlTest	add one, or decide suite level meta groups are not expressible
suite level <dependencies>	same shape: no xmlDependencyGroups on XmlSuite	same

The first two are the cheap ones and would close the two gaps a user is most likely to hit.

Reader inconsistencies found on the way

• XmlInclude indices are never assigned. Yaml.parse renumbers tests and classes after
  loading (t.setIndex, c.setIndex) but not includes, so every include coming from YAML has
  index 0 while TestNGContentHandler numbers them across the class. Two includes of the same
  class are therefore indistinguishable by index. Visible as a digest difference when converting
  yaml/a2.xml through the Converter CLI, even though both include names survive.
• ConstructXmlScript always builds an XmlScript. Even for a className-only method
  selector it creates an empty script and calls setScript, so a suite read from YAML has a
  non-null-but-empty script where the same suite read from XML has null.
• TypeDescription.addPropertyParameters("method-selectors", ...) is dead code.
  TypeDescription is keyed by property name and there is no method-selectors property; the
  binding works through the generic signature of getMethodSelectors(). Both registrations in
  Yaml.parse can go.
• packages and xmlPackages are both valid keys on XmlSuite and XmlTest (alias
  getter/setter pairs). The writer picked packages; the contract should say so, or drop one.

Not a gap

guiceStage: DEVELOPMENT appears in the YAML written for any suite parsed from XML. That is not
the writer inventing a value: the DTD declares guice-stage ... "DEVELOPMENT" as a default
attribute value, so the validating parser supplies it. XmlSuite.toXml() writes it out for the
same reason.