Convert .md links in rule documentation to full URLs

[InSyncWithFoo]

Summary

Related to these comments at #15862 and #15889.

Markdown links of the following format are an anti-pattern:

[`rule-name`](rule-name.md)

Only Mkdocs can resolve such links. When rendered by a client, typically an editor, they lead to nowhere. This might cause some frustration. Additionally, documentation for other rules (e.g., D211 and S606) uses the full URL form.

All such instances have thus been converted to full URLs:

[`rule-name`][A123]

[A123]: https://docs.astral.sh/ruff/rules/rule-name/

Test Plan

None.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

Only Mkdocs can resolve such links. When rendered by a client, typically an editor, they lead to nowhere. This might cause some frustration.

I generally view the doc-comments for the diagnostic structs themselves as external, user-facing documentation rather than internal, developer-facing documentation. So for these doc-comments, it's much more important to me how they're rendered on our website than it is how they're rendered in a tooltip by an editor. (This is the opposite from most other doc-comments we have in the codebase, which are generally just for internal documentation.) We also have lots of other special links in these doc-comments that are understood by mkdocs but that I doubt will be rendered well in an editor tooltip -- e.g. [`preview`] will link to https://docs.astral.sh/ruff/preview/ even if [preview]: https://docs.astral.sh/ruff/preview/ is not at the bottom of the diagnostic struct's doc-comment.

However, I don't think these changes do any harm (other than maybe hardcoding our website domain in a few more places). I'm okay with them if others are.

[InSyncWithFoo]

I generally view the doc-comments for the diagnostic structs themselves as external, user-facing documentation rather than internal, developer-facing documentation.

It is precisely due to them being user-facing that the links must be made accessible. ruff rule exists, and, as someone who uses the docs very often (IDE popups, command line, even rendered documentation view in RustRover), I want a better experience.

[MichaReiser]

I sort of agree with @AlexWaygood but I also see @InSyncWithFoo's point.

My preferred solution would be to move the link generation to the mkdocs script. E.g., could the script automatically detect rule codes in [] and replace them with the full URL, similar to what we already do with options?

I'm okay landing this as a separate PR

[AlexWaygood]

Yeah, I admit I hadn't considered what the output of ruff rule would look like. Ideally I feel like we'd have "clean" doc-comments with links generated by mkdocs, but that we'd also "fixup" the doc-comment before printing it to the terminal in the ruff rule output. Then links like the ones that mkdocs generates for [`preview`] would also be clickable from the terminal if you ran ruff rule. This might be an unreasonable amount of complexity to add to ruff rule, though