Make SonarCloud job use Java 17

[beatngu13]

Via Sonar Commmunity:

We wanted to give you a heads-up that we’re moving away from supporting Java 11 as a runtime environment for the Scanners. We’re encouraging everyone to migrate their scan pipelines to Java 17 as soon as possible. The documentation has been updated accordingly for SonarCloud. For SonarQube, Java 11 will be deprecated starting from SonarQube 10.2, and SonarQube 9.9 LTS is not impacted.
We do this move because Java 21 is arriving soon on the 19th of September 2023 and our policy is to only support the two latest Java LTS.

We plan to drop support for Java 11 as a runtime environment on November 15th, 2023.

Currently, we run our SonarCloud analysis as part of our basic job:

junit-pioneer/.github/workflows/build.yml

Lines 81 to 86 in 13c2c4d

	- name: SonarCloud analysis
	if: ${{ matrix.os == 'ubuntu' }}
	env:
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	SONAR_TOKEN: "61ab2579215aa8a0024a2f9368fc1298fdecfd18"
	run: ./gradlew jacocoTestReport sonarqube --stacktrace -i

I see two options:

1. Let the basic job use Java 17 (still targeting 11 with --release, as we already do).
2. Introduce a separate (possibly parallel) analysis job, similar to e.g. code-format-check, using Java 17.

[Bukama]

I would vote for the second solution (or extend the code-format-check one) as the --release parameter on a higher JDK can still bring up other results as far as I know, e.g. with the SecurityManager things.

[nipafx]

Related to #785: When we build an MR-JAR that contains, e.g., JDK 21 bytecode, it would probably be easiest to move the entire build to 21.