Ignore/fix broken links

Problem: several links in Markdown files are broken.

Solution:
1. Links in References.md, index.md and TechnicalReports.md
are invalid in the sense of Markdown and this repo, but
they work on the website, so they are explicitly ignored.
2. Glossary.md contains many links to anchors in the same file.
These anchors work differently in Markdown and Docusarus as can
be seen here:
https://ouroboros-consensus.cardano.intersectmbo.org/docs/for-developers/Glossary/
Ideally, they should be fixed to work on the resulting website,
in which case all of them would be broken in the sense of Markdown.
Fixing them for Docusaurus is out of scope of this commit,
but we force xrefcheck to ignore all links in that file in
preparation for that fix.
3. There is also an anchor link in VersioningSchemeDecision.md,
but this file is not used in the resulting website, so we fix
it according to Markdown rules.

docs/website/contents/about-ouroboros/References.md

@@ -2,6 +2,7 @@
 
 The following artifacts influence and/or describe the Consensus implementation.
 
+<!-- xrefcheck: ignore link -->
 * [Technical reports](../for-developers/TechnicalReports)
 * From the IOG researchers:
     * [Ouroboros BFT][ouroboros-bft]

docs/website/contents/about-ouroboros/index.md

@@ -48,6 +48,7 @@ used to ensure that -- unless an adversary controls more than half of the net's
 stake -- the honest nodes will all continually reach _consensus_ regarding the
 selection of a single best chain and that that chain grows over time.
 
+<!-- xrefcheck: ignore link -->
 The Consensus Layer defines the core Consensus components and logic, notably the
 Ouroboros protocol. See [References](References).
 

docs/website/contents/for-developers/Glossary.md

@@ -1,3 +1,4 @@
+<!-- xrefcheck: ignore file -->
 # Glossary
 
 Notes on the use and maintenance of this glossary:

docs/website/contents/for-developers/TechnicalReports.md

@@ -4,12 +4,15 @@ The following artifacts influence and/or describe the Consensus implementation.
 
 ## Consensus and networking
 
+<!-- xrefcheck: ignore link -->
 * [The Cardano Consensus and Storage Layer](/pdfs/report.pdf).
 * [Introduction to the design of Data Diffusion and Networking of Cardano Shelley][network-report].
 
 ## UTxO-HD
 
+<!-- xrefcheck: ignore link -->
 * [Storing the Cardano ledger state on disk: analysis and design options (An IOHK technical report)](/pdfs/utxo-db.pdf)
+<!-- xrefcheck: ignore link -->
 * [Storing the Cardano ledger state on disk: API design concepts (An IOHK technical report)](/pdfs/utxo-db-api.pdf)
 
 

docs/website/contents/for-developers/VersioningSchemeDecision.md

@@ -495,7 +495,7 @@ This rule is so simple that the ✗ for EasyPR is somewhat surpising.
 The hidden problem is that this scheme causes spurious merge conflicts among all your PRs.
 It would only be possible to merge PRs sequentially and merging one PR requires rebasing every other PR and updating its version number diff (assuming a single target branch).
 That usually implies a very poor contributor experience.
-(If you're wondering about variations on this, such as "only bump the version if it hasn't already been bumped", see [below](#RisingEdgeCompromises).)
+(If you're wondering about variations on this, such as "only bump the version if it hasn't already been bumped", see [below](#possible-risingedge-compromises).)
 
 We assign ✓ for EasyRelease because each release doesn't require any additional work; merely announce the result of the latest PR.
 Relatedly, though, we assign ✗ for TypicalReleases because it's unrealistic to release after every PR.