chore: avoid Java version mismatch (alternative mix of Java 8 & Java 11)

[nielspardon]

Another alternative to #433 which requires less changes.

Mainly:

• the Jabel plugin handles some of the differences between Java 17 and Java 8
• explicitly configures the compiler version to be Java 17
• runs core tests on a JVM with the corresponding release level (core = Java 8, everything else = Java 11)
• configures same Scala release level as Java release level (Java 11)

Downside of the approach is that we are still relying on Jabel to enable a subset of the newer Java syntax to be compiled by the Java compiler to Java 8 compatible bytecode while especially for Java API changes we may still need to write code that only uses the APIs available in Java 8 or Java 11 depending on the module.

[bestbeforetoday]

This change uses within the same task both of these options:

sourceCompatibility = "17"
options.release = 8

The Java 17 javac spec says:

Note: When using --release, you cannot also use the --source/-source or --target/-target options.

Mixing these options (along with targetCompatibility and using Jabel) is the reason for the build issues addressed by #433. It is not clear to me how this change is an alternative to that PR.

[nielspardon]

Mixing these options (along with targetCompatibility and using Jabel) is the reason for the build issues addressed by #433. It is not clear to me how this change is an alternative to that PR.

See my comment here: #443 (comment)

This alternative tries to create a more deterministic build behavior. Specifically in configuring the Gradle toolchain plugin to select the same JDK consistently and not randomly selecting a different JDK version without changing large amounts of Java code. As I stated above this does not solve all issues with the Jabel approach.