Stop rendering CS modules and room version fragments as standalone pages (#1317)

This is actually doing two things:

 * creating `{fragments,modules}/index.md` turns the fragments and modules into
   page resources, rather than pages in their own right. We have to update the
   shortcodes to match.

 * adding `headless: true` means that we don't render the pages.

The net effect is that we don't render pages like
https://spec.matrix.org/v1.4/rooms/fragments/v1-auth-rules/ and
https://spec.matrix.org/v1.4/client-server-api/modules/account_data/.

content/rooms/fragments/index.md

@@ -0,0 +1,3 @@
+---
+headless: true
+---

content/rooms/fragments/v1-auth-rules.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 The types of state events that affect authorization are:
 

content/rooms/fragments/v1-canonical-json.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Servers MUST NOT strictly enforce the JSON format specified in the
 [appendices](/appendices#canonical-json) for the reasons

content/rooms/fragments/v1-deprecated-formatting-off-spec.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events sent into rooms of this version can have formats which are different
 from their normal schema. Those cases are documented here.

content/rooms/fragments/v1-redactions.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

content/rooms/fragments/v1-stringy-power-levels.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 ##### `m.room.power_levels` events accept values as strings
 

content/rooms/fragments/v2-state-res.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 The room state *S′(E)* after an event *E* is defined in terms of the
 room state *S(E)* before *E*, and depends on whether *E* is a state

content/rooms/fragments/v3-auth-rules.md

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{< added-in this=true >}} In room versions 1 and 2, events need a
 signature from the domain of the `event_id` in order to be considered
 valid. This room version does not include an `event_id` over federation

content/rooms/fragments/v3-handling-redactions.md

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{% added-in this=true %}} In room versions 1 and 2, redactions were
 explicitly part of the [authorization rules](/rooms/v1/#authorization-rules)
 under Rule 11. As of room version 3, these conditions no longer exist as

content/rooms/fragments/v4-event-format.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events in rooms of this version have the following structure:
 

content/rooms/fragments/v4-event-ids.md

@@ -1,7 +1,5 @@
 ---
-toc_hide: true
 ---
-
 {{% added-in this=true %}} The event ID is the [reference
 hash](/server-server-api#calculating-the-reference-hash-for-an-event) of
 the event encoded using a variation of [Unpadded

content/rooms/fragments/v5-signing-requirements.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 When validating event signatures, servers MUST enforce the
 `valid_until_ts` property from a key request is at least as large as the

content/rooms/fragments/v6-canonical-json.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Servers MUST strictly enforce the JSON format specified in the
 [appendices](/appendices#canonical-json). This translates to a

content/rooms/fragments/v6-redactions.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

content/rooms/fragments/v8-auth-rules.md

@@ -1,6 +1,3 @@
----
-toc_hide: true
----
 
 Events must be signed by the server denoted by the `sender` property.
 

content/rooms/fragments/v9-redactions.md

@@ -1,5 +1,4 @@
 ---
-toc_hide: true
 ---
 
 {{% added-in this=true %}} `m.room.member` events now keep `join_authorised_via_users_server`