Consisent x- Param/Encoding/Header wording (3.0.4)

It was a bit challenging to figure out where to put the wording
about allowing extension parameters when there are multiple
fixed fields tables, each in their own subsection.

For the Parameter Object (the only one with multiple tables in
past releases), it had been after the last table, but that got
further and further away from what felt like the main part of
the Object description.

I thought I had put it consistently after the initial
"Common Fixed Fields" table, but I put it even before that in
one place (which we don't do anywhere), and I forgot to include
it in the Header Object at all.

This change puts it after the Common Fixed Fields table for
all three, which means that for all Objects it is immediately
after the first Fixed Fields table.

Author: handrews

versions/3.0.4.md

@@ -1108,8 +1108,6 @@ The rules for serialization of the parameter are specified in one of two ways.
 Parameter Objects MUST include either a `content` field or a `schema` field, but not both.
 See [Appendix B](#dataTypeConversion) for a discussion of converting values of various types to string representations.
 
-This object MAY be extended with [Specification Extensions](#specificationExtensions).
-
 ###### Common Fixed Fields
 
 These fields MAY be used with either `content` or `schema`.
@@ -1123,6 +1121,8 @@ Field Name | Type | Description
 <a name="parameterDeprecated"></a> deprecated | `boolean` | Specifies that a parameter is deprecated and SHOULD be transitioned out of usage. Default value is `false`.
 <a name="parameterAllowEmptyValue"></a> allowEmptyValue | `boolean` | If `true`, clients MAY pass a zero-length string value in place of parameters that would otherwise be omitted entirely, which the server SHOULD interpret as the parameter being unused. Default value is `false`. If [`style`](#parameterStyle) is used, and if [behavior is _n/a_ (cannot be serialized)](#style-examples), the value of `allowEmptyValue` SHALL be ignored. Interactions between this field and the parameter's [Schema Object](#schemaObject) are implementation-defined. This field is valid only for `query` parameters. Use of this property is NOT RECOMMENDED, and it is likely to be removed in a later revision.
 
+This object MAY be extended with [Specification Extensions](#specificationExtensions).
+
 Note that while `"Cookie"` as a `name` is not forbidden with `in: header`, the effect of defining a cookie parameter that way is undefined; use `in: cookie` instead.
 
 ###### Fixed Fields for use with `schema`
@@ -2493,6 +2493,8 @@ Field Name | Type | Description
 <a name="headerRequired"></a>required | `boolean` | Determines whether this header is mandatory. The default value is `false`.
 <a name="headerDeprecated"></a> deprecated | `boolean` | Specifies that the header is deprecated and SHOULD be transitioned out of usage. Default value is `false`.
 
+This object MAY be extended with [Specification Extensions](#specificationExtensions).
+
 ##### Fixed Fields for use with `schema`
 
 For simpler scenarios, a [`schema`](#headerSchema) and [`style`](#headerStyle) can describe the structure and syntax of the header.