After the cut, release/5.x's own changelogs and READMEs link main, and DocumentationLinkTests checks them against the 5.x tree #161

Found while fixing #151 (#158).

#158 freezes the links in what ships: the packed release notes, the packed READMEs and the GitHub release's notes link blob/v<version> instead of blob/main. What it leaves alone is the source on release/5.x after the v5.5.0 cut. There, the root and package changelogs (about 150 links), the packed READMEs' sources and CONTRIBUTING's changelog rule all still say https://github.com/CaffeinatedCoder/EFCore.ComplexIndexes/blob/main/....

What happens

• Browsing release/5.x on GitHub: the changelog's guide links and the READMEs' docs links open main, which is SchemaKit's documentation.
• DocumentationLinkTests.Absolute_links_into_this_repository_resolve keeps passing on release/5.x, because it resolves blob/main/... against the checkout, which is the 5.x tree. What GitHub actually serves at those URLs is main's tree. On that branch the test checks something other than what the links open.
• New 5.x changelog lines: CONTRIBUTING tells contributors to write blob/main. That link resolves locally and points at SchemaKit online.

Published artifacts are not affected, since #158 rewrites at pack and release time. On a 5.x tag, the test's checkout is the tag's tree, so the frozen links are still proven.

Options

• At the cut, rewrite blob/main/ to blob/release/5.x/ on release/5.x. Make DocumentationLinkTests (and Link the docs at the version's tag in published notes and READMEs #158's pack rewrite) take the branch prefix from one property per line.
• Or accept it: browsing a release branch is rare, and the artifacts are right. Say so in CONTRIBUTING's "At the v5.5.0 tag" so nobody expects otherwise.

This needs a decision before or at the cut, not before the tag.