docs: checklist for adding or changing a .cabal file format field

[andreabedini]

Summary

Adds a new section to CONTRIBUTING.md, "Adding or changing a .cabal file format field", documenting how to correctly gate new or changed .cabal fields behind cabal-version.

This is the class of bug described in #9331: when a new field is not gated, an older Cabal/cabal-install silently accepts it and does the wrong thing, or a newer field leaks into a package that claims an old cabal-version. Features that influence generated files (Paths_*.hs, cabal_macros.h, autogen sources, …) are especially dangerous when ungated.

I tried to be as clear as possible, please review and suggest changes.

What it documents

A step-by-step checklist around the CabalSpecVersion enum:

1. Ensure a CabalSpecVersion constructor exists for the next unreleased (even) spec version — and that adding one is an API-breaking change requiring a major version bump, with the total functions that must be extended.
2. Bump cabalSpecLatest in the same change, so the constructor and cabalSpecLatest never drift apart.
3. Gate the field in FieldGrammar.hs with availableSince <literal constructor> [] — not the name cabalSpecLatest, which would retroactively move the field's introduction version forward on every spec bump.
4. Add the matching checkSpecVer in Cabal/.../Check/Target.hs so cabal check reports the field used below its introduction version.
5. Document the change in doc/file-format-changelog.rst and add a changelog.d/ entry.

Type of change

Documentation only — no code changes, no changelog entry required.

[Copilot]

Pull request overview

This PR adds a new CONTRIBUTING guide section describing the required workflow for introducing or changing .cabal file format fields, with a focus on correctly gating syntax behind cabal-version (and ensuring cabal check enforces the introduction version) to prevent issues like #9331.

Changes:

• Documented a step-by-step checklist for adding/changing .cabal fields, centered on CabalSpecVersion and cabalSpecLatest.
• Documented the correct way to gate fields in FieldGrammar.hs (and why not to use cabalSpecLatest by name).
• Documented adding the corresponding checkSpecVer enforcement in Cabal/.../Check/Target.hs, plus changelog updates.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Mikolaj]

@andreabedini: do you think the Copilot's comments are worth answering? Ideally, I'd not review while the PR is in the middle of other changes.

[andreabedini]

@Mikolaj I believe the comments have been addressed.

[Mikolaj]

LGTM

[angerman]

I hope that AIs (if they end up being used) find this helpful as well! Or hold their meat proxies to this checklist!