Make JDK bundling reproducible.

[andsel]

Problem context

The issue #15513 highlighted a problem with Logstash's versions.yml file, related to JDK.
In that file the exact version of the JDK is defined, for example 17.0.9+9 separated by revision and build. Revision is composed of major.minor.patch .
However build is not always the same across OS / architecture, so could happen that exists a version for Linux named 17.0.9+9 and one for Windows 17.0.9+9.1, where version 17.0.9+9 for Windows simply has never existed (or was junked).

To avoid the problem of tracking different build numbers for same JDK version, PR #15514 switched to download from Elastic's own jvm catalog instead of direct links to Adoptium, but this introduced non reproducibility on releases.
The JVM catalog lists JDKs only by major version so 17.0.9 can't be referred, but only 17. This imply that if on day 1 the JDK version downloaded from catalog is effectively 17.0.9 at some later time, if the catalog is updated with a newer version, the build of Logstash implicitly bring a fresher version which doesn't necessarily correspond with what is specified in versions.yml.

This generates two problems:

• non repeatable builds. From same commit of Logstash we could obtain different artifacts, depending on the day it's builta.
• make difficult to know effectively which JDK is bundled with a version of Logstash. To check the version bundled with Logstash is not anymore sufficient to look into the file versions.yml, but Logstash package has to be downloaded and run, to look at the console (or check in the JDK_VERSION file) for bash script output.

Desired behaviour

The version (aka revision in version.yml) must be consistent, respect to the version numbers while build numbers can differ.
Leverage the Elastic's jvm catalog for better stability when downloading JDKs, if possibile, instead from Adoptium repository.