feat(CI): Add CI check that detects an outdated SPDX license list

[zlonast]

Add a scheduled GitHub Actions workflow that compares the newest SPDX license
list version tracked in the repository against the latest release published
upstream in spdx/license-list-data. When a newer version is available, the
job fails with instructions to download the new data files into
license-list-data/, add the version to SPDX_LICENSE_VERSIONS in the
Makefile, and regenerate the license modules with make -B spdx.

---

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[ffaf1]

If I understand this correctly, a PR from a new contributor could be ok one day and the next (upon changes) blocked by this check?

I am not happy about this (I am quite happy about make -b spdx).

[zlonast]

@ffaf1 I'm not sure we need to enforce this so strictly, so maybe you're right.

Anyway, here's an idea I liked:

---

The check is deliberately not a PR gate — it's a standalone schedule + workflow_dispatch job, so it never runs on a contributor's PR and can't block it.

• Day 1 — upstream SPDX list is 3.28, our repo ships 3.28. Scheduled check is green. A PR is mergeable and license: is parsed against the correct list.
• Day 2 — SPDX publishes 3.30. Our repo still ships 3.28. The contributor's PR is still mergeable — this check doesn't run on PRs and doesn't block anything. The only thing that changes is the scheduled job turns red, as a signal to maintainers: "3.30 is out, please update."
• Day 3 — a maintainer adds license-list-data/{licenses,exceptions}-3.30.json, bumps SPDX_LICENSE_VERSIONS in the Makefile, runs make -B spdx. Scheduled job is green again.