Simplify support of new Java versions

[keithc-ca]

The work leading up to and including #3714 eliminated the various complexities of managing several redirector variants: we should apply the same thinking to the JVM and JCL shared libraries. As the VM is built, JAVA_SPEC_VERSION identifies the version requirements.

Removing the extra JVM variants should be relatively straight-forward: we can use UMA directives:

<group name="jdk11">
	<include-if condition="spec.java11"/>
</group>

or cmake conditionals:

if(JAVA_SPEC_VERSION GREATER_EQUAL 11)
	# additions for Java 11+
endif()

to the description of a single JVM to account for version differences.

Similar changes address most of the issues for a single JCL, but the tool that generates the various j9vmconstantpool_*.c files will need to be changed to ease introduction of new versions. I propose to replace jcl xml attributes such as

<classref name="java/lang/LayerInstantiationException" jcl="se9,se10,se11,se12" flags="opt_module"/>

with

<classref name="java/lang/LayerInstantiationException" versions="9-" flags="opt_module"/>

which will not need to be modified to add support for Java 13, for example. (The opt_module flag may even be redundant.)

When running VMCPTool.Main, the -jcls se7_basic,se9_before_b165,se9,se10,se11,se12 option is replaced by -version $(VERSION_MAJOR) to specify the desired content of j9vmconstantpool.c (only one C file is generated - the one suitable for the JVM being built).

[pshipton]

@DanHeidinga @JasonFengJ9

[JasonFengJ9]

Agreed this is the right way. Just throw couple of corner cases for consideration,

1. A class/field removed or renamed at a later version;
2. A class/field removed or renamed within same version during development;

In first case, need some range definitions like [7, 9) or [9, 12] besides 9- or 11+.
For second case, it refers a scenario that one VM need accommodate two incompatible JCL extension levels (or tags) with same version. It is not a usual thing, but it did happen. If this can be added without lots of effort, please give a try during design.

[keithc-ca]

See [1] for an example of how the elimination of the field exception from java.lang.ExceptionInInitializerError in Java 12 is handled.

Case 2 is no different. Whenever the change occurs, a matching change to openj9 must be made (even with the current tools).

[1] https://github.com/keithc-ca/openj9/blob/abc9e3d3855426b2b01a93a4802939bb0054d7bd/runtime/oti/vmconstantpool.xml#L193

[keithc-ca]

I think we can consider this resolved.