Follow-up from @JacobCoffee's review on #20777 (#20777 (review)).

Problem

Our three MkDocs sites (user docs, dev docs, blog) use lots of inline [thing](https://...) links, and many of the same URLs are repeated across files. For example, https://docs.pypi.org/trusted-publishers/ appears 12 times and the api/json/ and api/index-api/ pages 6 times each.

So when a URL changes (as with the /help deprecation in #20777), we have to edit every occurrence. That makes for noisy diffs and harder reviews, and it's easy to miss one.

Proposal

Keep one shared file of reference-style link definitions and include it in every docs site, for example:

[pypi-2fa]: https://docs.pypi.org/your-account/two-factor-authentication/
[pypi-api-tokens]: https://docs.pypi.org/publishing/publishing-to-pypi/#using-an-api-token
[pypi-account-recovery]: https://docs.pypi.org/your-account/account-recovery/

Pages would then use reference links:

Enable [two-factor authentication][pypi-2fa].

A changed URL then needs one edit in one place, and the Markdown source is easier to read.

One possible approach is pymdownx.snippets with auto_append. It would append the shared links file to every page in mkdocs-user-docs.yml, mkdocs-dev-docs.yml and mkdocs-blog.yml. None of these configs enable snippets today.

Trade-offs / open questions

• Readers of the raw Markdown have to look up where a reference points. The reviewer thinks this is worth it.
• Naming convention for link keys (e.g. pypi-*, pug-* for packaging.python.org)
• Should the blog be included? Old posts may intentionally link to URLs as they were at the time.
• Can we catch undefined or unused references in CI? A dangling [text][ref] renders as literal text rather than failing the build.
• Should we migrate existing links all at once, or gradually as files are touched?