Report EOL and maintenance status for Gradle versions (#1057)

This PR reports the support status of every Gradle version used in a
workflow:

- **End-of-life** — two or more major versions behind the latest
release.
- **Out of date** — one major version behind the latest release, or more
than two minor versions behind on the current major.

The information is surfaced as job annotations and in the Job Summary:
an icon beside the Gradle version in the build results table, and a
message below it.

| version kind | job annotation | version table | below the table |
| ------ | ----- | ---- | --------- |
| EOL | warning | ⚠️ | expandable section, pointing to the Gradle
Security Subscription |
| Out of date | notice | ℹ️ | one-line legend, pointing to the Gradle
release lifecycle docs |
| Current | none | — | — |

A single expandable section covers every end-of-life version, naming
them in its summary line and listing the affected release lines in its
body. The upgrade legend likewise appears once per job, however many
versions carry the info icon.

Notes on what is deliberately *not* reported:

- **Patch releases.** Only the major and minor version are considered,
so being on `9.7.0` when `9.7.1` exists is not flagged.
- **Pre-releases.** Release candidates, milestones and snapshots are
never reported, so testing against a nightly or an RC produces no
annotations.

The latest Gradle release is determined from the wrapper checksum data
already bundled with the action, so no network access is required. That
data is refreshed weekly, and the two-minor grace band absorbs the lag.

Note that the annotations are emitted independently of
`add-job-summary`: setting it to `never` suppresses the Job Summary
itself, but the warning and notice annotations remain.

### Examples

The `demo-job-summary` workflow has a `support-status-eol-and-outdated`
job that builds with three end-of-life versions (`6.9.4`, `7.4`,
`7.6.6`), two out-of-date versions (`8.0.2`, `8.14.5`) and the current
release, so all three statuses appear in one summary:

* **Job Summary**:
https://github.com/gradle/actions/actions/runs/34166688755#summary-101879071306
* **Annotations**:
https://github.com/gradle/actions/actions/runs/34166688755/job/101879071306
(expand annotations)

That workflow is never triggered automatically; run it manually against
a branch to review the rendering.

### Implementation

* Adds `GradleVersion`, parsing and ordering versions the same way
Gradle's own `org.gradle.util.GradleVersion` does. This replaces the
previous `versionIsAtLeast` helper and removes the `semver` dependency.
* Adds `gradle-support-status.ts`, which owns the classification policy
and both of its presentations (annotations and Job Summary section)
behind a three-function API, so `job-summary.ts` only asks for the icon
and the rendered block.

### Testing

* Unit tests for version ordering, classification, the annotations and
the rendered summary.
* `integ-test-gradle-support-status.yml`, which derives its expected
versions from the bundled release data so the assertions cannot drift
from the action's own view, then asserts against the real job log.
* The demo workflow job linked above, for reviewing the rendering by
eye.

Documented under [Build
reporting](https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#gradle-version-support-status)
in `docs/setup-gradle.md`.

---------

Co-authored-by: Louis Jacomet <louis@gradle.com>
Co-authored-by: Daz DeBoer <daz@gradle.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/setup-gradle.md

@@ -518,6 +518,30 @@ so that a Job Summary is never generated, or so that a Job Summary is only gener
 add-job-summary: 'on-failure' # Valid values are 'always' (default), 'never', and 'on-failure'
 ```
 
+### Gradle version support status
+
+The Job Summary reports the support status of each Gradle version used in the workflow, and the action adds a
+Job annotation for any version that is no longer current. The latest Gradle release is determined from release data
+bundled with the action, so no network access is required.
+
+A version is reported when it is:
+- **End-of-life** — two or more major versions behind the latest release. Each such version is marked with :warning:
+  in the build results table, a single expandable section below the table explains that the affected release lines
+  receive no further fixes (security fixes included), and a warning annotation is added to the Job for each version.
+  If you cannot upgrade, the [Gradle Security Subscription](https://gradle.org/security-subscription/) offers
+  continued support for older versions.
+- **Out of date** — one major version behind the latest release, or more than two minor versions behind on the current
+  major. The version is marked with :information_source: in the build results table and a notice annotation is added to
+  the Job. Note that a version one major behind is still in "maintenance only" support and receives critical bug fixes
+  and security fixes; an older minor of the current major has simply been superseded. See
+  [Gradle release lifecycle](https://docs.gradle.org/current/userguide/feature_lifecycle.html#eol_support) for details.
+
+Patch releases are not reported: only the major and minor version are considered. Release candidates, milestones and
+snapshots are never reported, so testing against a pre-release build will not produce annotations.
+
+Note that these annotations are always emitted, independent of the `add-job-summary` setting. Setting
+`add-job-summary: 'never'` suppresses the Job Summary itself, but the warning and notice annotations remain.
+
 ### Excluding specific Gradle builds from Job Summary
 
 The Job Summary works by installing an init-script in Gradle User Home which will record details of any Gradle execution during the workflow.