vmVersionRanges might be a single version like "9", a list of versions
like "1.2,1.3,1.4,1.5", an equivalent range of "1.2-1.5", an open range
like "-1.8", "9-" (equivalent to "9+") or a more complex list of ranges
like "-1.6,9-11,13-14,17-" or "8,11,16+".

Empty ranges like in "", " ",  "8,,14", ",5", "6-," will be ignored.
I.e., they will not yield a positive match.

Bogus ranges like "9-11-14" will be ignored, too.

Existing XML test specs using '<line text="..." vm="v,v2,...,vn"/>
have been adjusted to use version ranges rather than long lists of
consecutive versions. Furthermore, ranges with a trailing '+' like '14+'
were replaced by using the new canonical format '14-', even though the
parser still correctly recognises '14+'.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Now there should be no more inspection warnings when working with XML
test definitions. Only the strangely looking XML files used by
PureJavaTests and KnownLimitationsTests are left to be analysed and
fixed.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

When trying to find out why ajc150.xml and ajc190_from150.xml look
almost identical, I found out that only in many cases the 190 version
has '-option="1.9"' set where in the 150 version it was '-option="1.9"'.

Unfortunately, in both files source/target versions are not set at all
in many places, which looks unintentional. I tried to search & replace
all relevant '<compile ...>' commands for 190 first, then ported back to
150. Only cases in which clearly compiling to an older version like 1.3
or 1.4 is necessary were left like before.

I am expecting missing or false Java target versions in many other of
the legacy XML test suites. For now, I am just committing these two.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

The goal is for them to be canonicalised to platform standard during
test execution. I am not sure if that will fix any tests, but at least I
hope it will not break any.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

The version handling in LangUtil has been overhauled
to cope better with post 1.8 releases (JDK9 and JDK10 or 18.3
or whatever they call it). As part of this moved
to treating JDK9 as '9' rather than '1.9'. Also removed
duplicate version processing logic and had that defer to
the one place in LangUtil where we now deal with it.

Includes some generics tidyup in ajdoc. More ajdoc work
is necessary for Java10 because it removes the standard doclet
(old style). However trying to invoke the internal Javadoc
handler in Java10 is failing due to module visibility rules.