Remove AdoptOpenJDK and Adopt OpenJ9 distributions in v6 #1183

Description:
Remove the legacy AdoptOpenJDK distributions from setup-java and document the required migration paths for users upgrading to v6:

• adopt and adopt-hotspot should be removed; users must migrate to temurin.
• adopt-openj9 should be removed; users must migrate to semeru / IBM Semeru.

Investigation notes:

• Runtime support still exists in src/distributions/distribution-factory.ts, where JavaDistribution.Adopt, JavaDistribution.AdoptHotspot, and JavaDistribution.AdoptOpenJ9 instantiate AdoptDistribution.
• The legacy implementation lives under src/distributions/adopt/ and still queries https://api.adoptopenjdk.net as a fallback for HotSpot and directly for OpenJ9.
• src/distributions/package-types.ts still exposes package capabilities for adopt, adopt-hotspot, and adopt-openj9.
• src/distributions/platform-types.ts still exposes platform capabilities for all three Adopt variants.
• Tests and fixtures still cover the legacy implementation, especially __tests__/distributors/adopt-installer.test.ts, __tests__/data/adopt.json, and platform/package references in related tests.
• Generated bundles in dist/ will need to be regenerated after source removal.

Documentation surfaces to update:

• README.md
  • Remove adopt, adopt-hotspot, and adopt-openj9 from the supported distributions table.
  • Remove adopt from the checksum verification list.
  • Replace the current note about AdoptOpenJDK migration with explicit v6 upgrade guidance.
  • Add/adjust migration examples showing adopt/adopt-hotspot -> temurin and adopt-openj9 -> semeru.
• docs/advanced-usage.md
  • Remove the Adopt section from distribution examples and the table of contents.
  • Remove Adopt rows from package compatibility and platform compatibility tables.
  • Update Java version file guidance so .tool-versions adoptopenjdk mappings are documented as compatibility/migration behavior, not as supported direct distribution values.
  • Replace examples that download from github.com/AdoptOpenJDK/... with Temurin/Adoptium equivalents where appropriate.
• Historical ADR references in docs/adrs/0000-v2-setup-java.md can remain if treated as history, but should not be used as current support documentation.

Behavior and compatibility considerations:

• Any direct reference to legacy Adopt distributions must be treated as an error, not a warning. Builds should fail fast before cache lookup or any vendor request.
• distribution: adopt, distribution: adopt-hotspot, and distribution: adopt-openj9 must not be treated as aliases for temurin, semeru, or any other distribution. Users must update the input explicitly.
• The error message should point users to the required replacement distribution: adopt/adopt-hotspot -> temurin; adopt-openj9 -> semeru.
• Users upgrading to v6 from older setup-java versions must update workflows before upgrading:

# AdoptOpenJDK HotSpot before
- uses: actions/setup-java@v5
  with:
    distribution: adopt
    java-version: '17'

# v6+
- uses: actions/setup-java@v6
  with:
    distribution: temurin
    java-version: '17'

# Adopt OpenJ9 before
- uses: actions/setup-java@v5
  with:
    distribution: adopt-openj9
    java-version: '17'

# v6+
- uses: actions/setup-java@v6
  with:
    distribution: semeru
    java-version: '17'

• .tool-versions / asdf inputs currently map adoptopenjdk to temurin, including adoptopenjdk-openj9 due to prefix collapsing. This compatibility behavior must be removed for v6: legacy Adopt vendor prefixes should not be silently remapped to supported distributions. They should produce a hard error that instructs users to choose temurin or semeru explicitly.

Justification:
AdoptOpenJDK moved to Eclipse Temurin and the AdoptOpenJDK catalogs are no longer the supported path for receiving current software and security updates. Adopt OpenJ9 users should move to IBM Semeru, which is the maintained OpenJ9 successor path already supported by setup-java.

Removing these legacy distribution values in v6 avoids continuing to advertise obsolete distributions, reduces maintenance around archived endpoints, and gives users a clear upgrade path before they move from older setup-java versions to v6.

Are you willing to submit a PR?
Yes.