The `r[frontmatter.document]` rule said "Frontmatter may only be
preceded by a shebang and whitespace", where the "and" could be
misread as requiring both a shebang and whitespace rather than listing
the set of things allowed to precede frontmatter.

Since we merged the shebang prose revision (#2192),
the shebang position rule now reads as a positive statement of where
the shebang may appear.  Let's follow the same pattern here: state
positively where frontmatter may appear rather than leaning on "only"
and a negative constraint.

In this commit, we rewrite the rule as "Frontmatter may appear at
the start of the file or after a shebang, in either case optionally
preceded by whitespace."  This resolves the ambiguity and parallels
the shebang position rule's structure.

The `r[frontmatter.document]` rule said "Frontmatter may only be
preceded by a shebang and whitespace", where the "and" could be
misread as requiring both a shebang and whitespace rather than listing
the set of things allowed to precede frontmatter.

Since we merged the shebang prose revision (#2192),
the shebang position rule now reads as a positive statement of where
the shebang may appear.  Let's follow the same pattern here: state
positively where frontmatter may appear rather than leaning on "only"
and a negative constraint.

In this commit, we rewrite the rule as "Frontmatter may appear at
the start of the file or after a shebang, in either case optionally
preceded by whitespace."  This resolves the ambiguity and parallels
the shebang position rule's structure.

The `r[frontmatter.document]` rule said "Frontmatter may only be
preceded by a shebang and whitespace", where the "and" could be
misread as requiring both a shebang and whitespace rather than listing
the set of things allowed to precede frontmatter.

Since we merged the shebang prose revision (#2192),
the shebang position rule now reads as a positive statement of where
the shebang may appear.  Let's follow the same pattern here: state
positively where frontmatter may appear rather than leaning on "only"
and a negative constraint.

In this commit, we rewrite the rule as "Frontmatter may appear at
the start of the file or after a shebang, in either case optionally
preceded by whitespace."  This resolves the ambiguity and parallels
the shebang position rule's structure.

The `frontmatter.document` rule said "Frontmatter may only be preceded
by a shebang and whitespace", where the "and" could be misread as
requiring both a shebang and whitespace rather than listing the set of
things allowed to precede frontmatter.

Since we merged the shebang prose revision (#2192),
the shebang position rule now reads as a positive statement of where
the shebang may appear.  Let's follow the same pattern here: state
positively where frontmatter may appear rather than leaning on "only"
and a negative constraint.

We'll also rename the rule identifier to `frontmatter.position` in
keeping with our conventions.

The `frontmatter.document` rule said "Frontmatter may only be preceded
by a shebang and whitespace", where the "and" could be misread as
requiring both a shebang and whitespace rather than listing the set of
things allowed to precede frontmatter.

Since we merged the shebang prose revision (#2192),
the shebang position rule now reads as a positive statement of where
the shebang may appear.  Let's follow the same pattern here: state
positively where frontmatter may appear rather than leaning on "only"
and a negative constraint.

We'll also rename the rule identifier to `frontmatter.position` in
keeping with our conventions.

In #2192, we extended our documentation about
shebangs but kept it in Input Format under a section on shebang
removal.  But really, this section is mostly now about documenting
what a shebang is, for our purposes.

Let's separate this out into a new subchapter.

We'll keep the rule about shebang removal in Input Format; it can link
to Shebang for a description of what a shebang is, its grammar, etc.

This follows the pattern that we'll similarly be using for
frontmatter.