dist: Migrate from Zulu Discovery API to Azul Metadata API (actions#1010)

* Use Azul metadata API

* Document arm64 -> aarch64 mapping in README.md

* Paginate through all available versions

* Fix typo: win_aarhc4

* Only query for linux_glibc packages

* Add Zulu CRaC package support to metadata migration

Fold CRaC-related work into the Zulu metadata API migration by wiring crac_supported query handling, extending Zulu package docs, and updating installer tests for jdk+crac/jre+crac behavior.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Harden Zulu metadata pagination with safety cap

- Stop paginating on a short page to avoid an extra empty request
- Guard against undefined results (not just null)
- Cap iterations at 100 pages and warn if the limit is hit to
  prevent a runaway loop if the API misbehaves

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Preserve JDK build number from Azul Metadata API

The Azul Metadata API returns java_version as a 3-element array
(e.g. [17,0,7]) and reports the build number separately in
openjdk_build_number. The migration mapped version directly from
java_version, dropping the build and breaking exact-version lookups
like 17.0.7+7 (e2e failure: "No matching version found for SemVer").

Add openjdk_build_number to IZuluVersions and append it to
java_version before converting to semver so resolved versions retain
the build (e.g. 17.0.7+7). Update the zulu test fixtures to mirror the
real API shape (3-element java_version plus openjdk_build_number) so
unit tests exercise the actual response format, and rebuild dist.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: 3 people

README.md

@@ -33,7 +33,7 @@ For more details,  see the full release notes on the [releases page](https://git
 
   - `distribution`: Java [distribution](#supported-distributions). Required unless `java-version-file` points to `.sdkmanrc` with a recognized distribution suffix (for example `java=21.0.5-tem`).
 
-  - `java-package`: The packaging variant of the chosen distribution. Possible values: `jdk`, `jre`, `jdk+fx`, `jre+fx`. Default value: `jdk`.
+  - `java-package`: The packaging variant of the chosen distribution. Possible values: `jdk`, `jre`, `jdk+fx`, `jre+fx`. For Azul Zulu, `jdk+crac` and `jre+crac` are also supported. Default value: `jdk`.
 
   - `architecture`: The target architecture of the package. Possible values: `x86`, `x64`, `armv7`, `aarch64`, `ppc64le`. Default value: Derived from the runner machine.
 
@@ -126,7 +126,7 @@ Currently, the following distributions are supported:
 > [!NOTE]
 > - The different distributors can provide discrepant list of available versions / supported configurations. Please refer to the official documentation to see the list of supported versions.
 > - AdoptOpenJDK got moved to Eclipse Temurin and won't be updated anymore. It is highly recommended to migrate workflows from `adopt` and `adopt-openj9`, to `temurin` and `semeru` respectively, to keep receiving software and security updates. See more details in the [Good-bye AdoptOpenJDK post](https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/).
-> - For Azul Zulu OpenJDK architectures x64 and arm64 are mapped to x86 / arm with proper hw_bitness.
+> - For Azul Zulu OpenJDK, architecture `arm64` is mapped to `aarch64` when querying the Azul Metadata API.
 > - To comply with the GraalVM Free Terms and Conditions (GFTC) license, it is recommended to use GraalVM JDK 17 version 17.0.12, as this is the only version of GraalVM JDK 17 available under the GFTC license. Additionally, it is encouraged to consider upgrading to GraalVM JDK 21, which offers the latest features and improvements.
 > - GraalVM Community is available as `distribution: 'graalvm-community'` for stable JDK 17 and later releases published on GitHub.