Allow a JSP option to accept java levels to at least 17

[epj]

Current behavior:
The JSP option jdkSourceLevel takes JDK compile level as a string without the decimal. When Liberty is running with up to Java 11, accepted values are "13", "14", "15", "16", "17" and "18" (which represent JDK versions 1.3, 1.4, 1.5, 1.6, 1.7 and 1.8 respectively). Specify anything else and it defaults back to "13". When Liberty is running with Java 12 or higher, the accepted values are "17" and "18".

The suggested change is to deprecate jdkSourceLevel, so it will be used to only specify one of "13", "14", "15", "16", "17" and "18". Further, the new JSP parameter javaSourceLevel will be introduced to specify the Java level from 8 on up to the current running Java level (both "8" and "1.8" will be accepted for Java 8 compile level).

[NottyCode]

I'm not keen on using 19, 110, 111 and 112 for Java 9, 10, 11 and 12 respectfully. I get that the versioning is going to be tricky once we get to Java 13 and we will have a Java 18 before Java 8 goes away I think it'll be a usability headache to prefix 1 on the front of everything given Java no longer versions 1.x

Could we consider essentially 'stabilizing' the jdkSourceLevel and introducing a javaSourceLevel which takes 1.7, 1.8, 9, 10, 11, 12? Also I suggest we just skip 9 and 10 since we never supported those non-LTS versions.

I'd also like to consider the implications of not specifying anything to mean use the same source level as the Java runtime being used.

[aguibert]

In the short term, this PR is needed for JDK 12 support and is closely related to this issue: #7202

[epj]

Also see #7181

[epj]

Making title more generic so specific solution isn't assumed from get go.

[epj]

Per the design meeting, I edited the 1st comment above to add to and clarify how this issue will address JSP compile levels for newer Java levels.

[volosied]

Documentation conversations: https://ibm-cloud.slack.com/archives/C31DW78RG/p1691439713384269