Add section titles, fix levels (3.1.1 port of 3923 2/6)

Make the Parameter, Encoding, and Header Object fixed fields
section organization the same in all three places, with the
same levels of indentation.

Add more headings under the Encoding Object for guidance on
each form media type, and sub-headings for each example in
each of those sections.

This will make the diff for the next commit much more legible.

Author: handrews

versions/3.1.1.md

@@ -1673,6 +1673,8 @@ In both cases, their order is implementation-defined.
 
 See [Appendix E](#percentEncodingAndFormMediaTypes) for a detailed examination of percent-encoding concerns for form media types.
 
+##### Fixed Fields
+
 ###### Common Fixed Fields
 
 These fields MAY be used either with or without the RFC6570-style serialization fields defined in the next section below.
@@ -1699,7 +1701,7 @@ Determining how to handle a `type` value of `null` depends on how `null` values
 If `null` values are entirely omitted, then the `contentType` is irrelevant.
 See [Appendix B](#dataTypeConversion) for a discussion of data type conversion options.
 
-##### Fixed Fields for RFC6570-style Serialization
+###### Fixed Fields for RFC6570-style Serialization
 
 Field Name | Type | Description
 ---|:---:|---
@@ -1712,11 +1714,15 @@ See also [Appendix C: Using RFC6570 Implementations](#usingRFC6570Implementation
 Note that the presence of at least one of `style`, `explode`, or `allowReserved` with an explicit value is equivalent to using `schema` with `in: query` Parameter Objects.
 The absence of all three of those fields is the equivalent of using `content`, but with the media type specified in `contentType` rather than through a Media Type Object.
 
+##### Encoding the `x-www-form-urlencoded` Media Type
+
 See [Appendix E](#percentEncodingAndFormMediaTypes) for a detailed examination of percent-encoding concerns for form media types.
 
 To submit content using form url encoding via [RFC1866](https://tools.ietf.org/html/rfc1866), the following
 definition may be used:
 
+###### Example: URL Encoded Form with JSON Values
+
 ```yaml
 requestBody:
   content:
@@ -1763,6 +1769,8 @@ Here is the `id` parameter (without `address`) serialized as `application/json`
 id=%22f81d4fae-7dec-11d0-a765-00a0c91e6bf6%22
 ```
 
+###### Example: URL Encoded Form with Binary Values
+
 `application/x-www-form-urlencoded` is a text format, which requires base64-encoding any binary data:
 
 ```YAML
@@ -1784,7 +1792,7 @@ requestBody:
       contentType: image/png, image/jpeg
 ```
 
-###### Encoding `multipart` Media Types
+##### Encoding `multipart` Media Types
 
 It is common to use `multipart/form-data` as a `Content-Type` when transferring request bodies to operations.  In contrast to 2.0, a `schema` is REQUIRED to define the input parameters to the operation when using `multipart` content.  This supports complex structures as well as supporting mechanisms for multiple file uploads.
 
@@ -1815,7 +1823,7 @@ If `contentEncoding` is used along with setting a different `Content-Transfer-En
 
 See [Appendix E](#percentEncodingAndFormMediaTypes) for a detailed examination of percent-encoding concerns for form media types.
 
-##### Encoding Object Example
+###### Example: Basic Multipart Form
 
 Examples:
 
@@ -1854,6 +1862,8 @@ requestBody:
               $ref: '#/components/schemas/Address'
 ```
 
+###### Example: Multipart Form with Encoding Objects
+
 `multipart/form-data` allows for binary parts:
 
 ```yaml
@@ -1891,6 +1901,8 @@ requestBody:
                 type: integer
 ```
 
+###### Example: Multipart Form with Multiple Files
+
 To upload multiple files, a `multipart` media type MUST be used:
 
 ```yaml
@@ -2566,7 +2578,9 @@ The Header Object follows the structure of the [Parameter Object](#parameterObje
 1. `in` MUST NOT be specified, it is implicitly in `header`.
 1. All traits that are affected by the location MUST be applicable to a location of `header` (for example, [`style`](#parameterStyle)).  This means that `allowEmptyValue` and `allowReserved` MUST NOT be used, and `style`, if used, MUST be limited to `simple`.
 
-##### Common Fixed Fields
+##### Fixed Fields
+
+###### Common Fixed Fields
 
 These fields MAY be used with either `content` or `schema`.
 
@@ -2578,7 +2592,7 @@ Field Name | Type | Description
 
 This object MAY be extended with [Specification Extensions](#specificationExtensions).
 
-##### Fixed Fields for use with `schema`
+###### Fixed Fields for use with `schema`
 
 For simpler scenarios, a [`schema`](#headerSchema) and [`style`](#headerStyle) can describe the structure and syntax of the header.
 When `example` or `examples` are provided in conjunction with the `schema` object, the example MUST follow the prescribed serialization strategy for the header.
@@ -2598,7 +2612,7 @@ Field Name | Type | Description
 
 See also [Appendix C: Using RFC6570 Implementations](#usingRFC6570Implementations) for additional guidance.
 
-##### Fixed Fields for use with `content`
+###### Fixed Fields for use with `content`
 
 For more complex scenarios, the [`content`](#headerContent) property can define the media type and schema of the header, as well as give examples of its use.
 Using `content` with a `text/plain` media type is RECOMMENDED for headers where the `schema` strategy is not appropriate.