PEP 675: nest sections under Specification (#2313)

They were top-level sections.

I also moved up the Runtime Behavior section to answer the question of
where LiteralString lives, since right now it's buried in the PEP.

pep-0675.rst

@@ -265,8 +265,24 @@ string type to specify that our API can only accept strings that are
 known to be constructed from literals. More specific details follow in
 the remaining sections.
 
+Specification
+=============
+
+
+Runtime Behavior
+----------------
+
+We propose adding ``LiteralString`` to ``typing.py``, with an
+implementation similar to ``typing.NoReturn``.
+
+Note that ``LiteralString`` is a special form used solely for type
+checking. There is no expression for which ``type(<expr>)`` will
+produce ``LiteralString`` at runtime. So, we do not specify in the
+implementation that it is a subclass of ``str``.
+
+
 Valid Locations for ``LiteralString``
-=========================================
+-----------------------------------------
 
 ``LiteralString`` can be used where any other type can be used:
 
@@ -292,12 +308,13 @@ It cannot be nested within unions of ``Literal`` types:
 
 
 Type Inference
-==============
+--------------
 
 .. _inferring_literal_string:
 
+
 Inferring ``LiteralString``
----------------------------
+'''''''''''''''''''''''''''
 
 Any literal string type is compatible with ``LiteralString``. For
 example, ``x: LiteralString = "foo"`` is valid because ``"foo"`` is
@@ -350,7 +367,7 @@ Such a refined type in the if-block is also compatible with
 
 
 Examples
---------
+''''''''
 
 See the examples below to help clarify the above rules:
 
@@ -456,7 +473,7 @@ Conditional statements and expressions work as expected:
 
 
 Interaction with TypeVars and Generics
---------------------------------------
+''''''''''''''''''''''''''''''''''''''
 
 TypeVars can be bound to ``LiteralString``:
 
@@ -502,8 +519,9 @@ Standard containers like ``List`` work as expected:
 
     xs: List[LiteralString] = ["foo", "bar", "baz"]
 
+
 Interactions with Overloads
----------------------------
+'''''''''''''''''''''''''''
 
 Literal strings and overloads do not need to interact in a special
 way: the existing rules work fine. ``LiteralString`` can be used as a
@@ -559,13 +577,6 @@ annotating it as ``x: LiteralString``:
     expect_literal_string(x)
 
 
-Runtime Behavior
-================
-
-We propose an implementation for ``typing.LiteralString`` similar to
-``typing.NoReturn``.
-
-
 Rejected Alternatives
 =====================