I've decided to break backwards compatibility with the way I've
overridden runS. The "proper" way would have been to call the one-arg
version from the two-arg version so that subclasses overriding runS
would still get their method called. But I figured it to be extremely
unlikely that such subclasses exist.

This closes #84 pull request at github/apache/ant repo

Use valid markup

Many thanks to Gintas (@twogee) for catching this

This closes #81 pull request at github/apache/ant

for each of the test class that are selected by the <testclasses> usage

In 1.10.5 version (the latest released) of Ant, we used to launch
multiple LauncherDiscoveryRequest (a JUnit 5 construct), one each
for a test class, that belonged to the <testclasses> usage. Commit
3f806148c3 changed it to launch one
single LauncherDiscoveryRequest (and including all those test
classes in that request) because it seemed more logical to do so.
However, recent tests/experimentation of the master branch has
shown that it introduces complexities when the "legacy-xml"
listener (the one which supports generating test results in xml
format that junitreport understands) is used. These complexities
include - expecting each test class to have a separate report file,
but isn't limited to that. Solving these issues isn't easy and
probably not worth it, given that the only reason we started using
a single LauncherDiscoveryRequest is because it just seemed logical
and there is no other strong reason to do so. This commit switches
back to the behaviour that's been there in 1.10.5 version, to issue
multiple separate LauncherDiscoveryRequest(s) one each for the
test class that's selected through the use of <testclasses>.