Spec URL fragment enumeration has a chance to bitrot when sections are shuffled/added/removed

Nobody has claimed this yet.

**Link to problem area**: The CS and S2S spec.

A related issue in ruma; https://github.com/ruma/ruma/issues/871

#### Issue
While discussing ways to make ruma's CI automatically detect link breakages, we discussed the way the spec's url fragments (the part after `#` in the url) are generated, and how they might change between versions.

Currently, they are enumerated from header names, and every duplicate header (an example being "Security Considerations") gets assigned a numerical suffix, e.g. `#security-concerns-1`

My concern arose from the fact that, inbetween spec versions, new sections might be introduced that have the exact same name, but shifting up the following sections in that enumeration, such that -2 might be instead linking to last spec's -1, or -3.

We check if the url fragment *exists*, but we cannot check wether or not this url fragment is *correct* when they're shifted upwards, and a situation might arise where we (ruma) are linking to an incorrect section of the spec by introducing the link in an older version, but bumping it for newer versions, and eventually arise at a different "point", if the spec has shifted sections inbetween versions.

#### Proposed Solution
What i'd recommend as a solution is to embed the header's full header numbering too, to reduce the chance of breakage, or at least make sure that it does not point to an incorrect header between versions.

It'd make the spec point to `#4.1.2.3-security-concerns`, instead of a naive enumeration, like above.

With this, there'd probably be churn on our side when the spec moves sections around between versions, but at least we can catch this automatically, instead of it silently bitrotting.

Start with the CS and S2S spec and trace how URL fragments are generated from header names, especially duplicate headers such as “Security Considerations.” Review the related ruma issue and compare the current enumeration with the proposed full-header-numbering approach. Done means section changes cannot silently redirect an existing fragment to a different section and resulting link changes are detectable.

Written by the indexing model from the issue text.