Revert behavior : the Gradle build does not require to use JDK 8 (temurin)

[Torch3333]

Description

Changes introduced by #1749 made the Gradle build require having a JDK 8 (temurin) installed on the system. This forced users cloning ScalarDB repository and using the master branch to have installed JDK 8 (temurin), which is inconvenient.
This PR reverts to the previous behavior, which is not to force Gradle to use a specific JDK. Users can use any JDK they desire to build ScalarDB.

Additionally, #1749 added Gradle project properties to configure Gradle to use a specific JDK version and vendor. This is left unchanged.

Related issues and/or PRs

• Run integration test with a given Java version and vendor #1749

Changes made

Updated JdkConfigurationPlugin to not require Java-related tasks to use JDK 8 (temurin). Java-related tasks will used by default the JDK used by Gradle.

Checklist

The following is a best-effort checklist. If any items in this checklist are not applicable to this PR or are dependent on other, unmerged PRs, please still mark the checkboxes after you have read and understood each item.

• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation to reflect the changes.
• Any remaining open issues linked to this PR are documented and up-to-date (Jira, GitHub, etc.).
• Tests (unit, integration, etc.) have been added for the changes.
• My changes generate no new warnings.
• Any dependent changes in other PRs have been merged and published.

Additional notes (optional)

N/A

Release notes

N/A

[feeblefakie]

LGTM! Thank you!

[jnmt]

LGTM! Thank you for quickly fixing it. I was able to confirm the behavior reverted in my environment.

[brfrn169]

LGTM! Thank you!

[komamitsu]

LGTM! Thank you!

[feeblefakie]

@Torch3333 The Cosmos DB integration test is failing. Can you check?

[jnmt]

@Torch3333 The Cosmos DB integration test is failing. Can you check?

@feeblefakie CI passed by retrying it since it was an out-of-memory error. So, I think we can merge this. (If the same issue occurs a lot, we might need to consider something, though.)

java.lang.AssertionError: 
Expecting actual throwable to be an instance of:
  com.scalar.db.exception.transaction.PreparationException
but was:
  java.lang.OutOfMemoryError: GC overhead limit exceeded

	at com.scalar.db.transaction.consensuscommit.TwoPhaseConsensusCommitSpecificIntegrationTestBase.commit_WriteSkewOnNonExistingRecordsWithSerializableWithExtraWrite_OneShouldCommitTheOtherShouldThrowPreparationException(TwoPhaseConsensusCommitSpecificIntegrationTestBase.java:2180)

[feeblefakie]

@jnmt Thank you!

[Torch3333]

@jnmt
Thanks for checking.

I noticed CosmosDB integration tests have been particularly flaky recently.