Encoding Object content and header clarifications (3.0.4)

[handrews]

Rendering with all currently open 3.0.4 changes (as of the timestamp of this edit - use the dropdown on the word "edited" in the bar for this comment) can be found here.

Fixes:

• Encoding object has style and contentType #1551 (by RECOMMENDING how to handle apparent contentType and style/explode/allowReserved conflicts)
• Questions about schemas for multipart and application/x-www-form-urlencoded request bodies #2282 (by clarifying how things are correlated between schema, encoding, and data)
• Clarification on support for application/json encoded object properties in application/x-www-form-urlencoded messages #3331 (similar to 1551)
• Encoding Object contentType field: "comma-separated list of the two types"? #3739 (by rephrasing how the comma-separated-list value of contentType works)
• other un-filed confusions such as the conditions under which headers can be used

The Encoding Object's contentType field takes a comma-separated list of either regular or wildcared media types. These are the "two types" mentioned in the previous wording – "two" here did not refer to a limit on the number of entries in the list.

These are not exactly media-type or media-range values, as both of those include parameters.

This change also moves the hard-to-follow list of default values out of the individual field cell and into its own table.

It takes Content-Disposition out of the header field's cell and instead explains limitations on header usage, and explains how Content-Disposition is used for encoding.

This explanation includes a suggestion on how other multipart formats could be used with an Encoding Object, since their unnamed parts otherwise cannot be supported.

Finally, it clarifies the interaction between contentType and the three fields imported from the Parameter Object, by aligning the recommended (but not, for compatibility reasons, required) behavior with guidance added in 3.1.0.

[notEthan]

looks good

[handrews]

@notEthan@ralfhandl I'm afraid I did a little re-arranging after resolving conflicts because it got less clear. This now splits the fields like they are in the Parameter Object and the Header Object (now that both of those have their own tables structured the same way, the Encoding Object became a weird exception to the pattern).

This will conflict with the percent-encoding PR, but it would have anyway. I'll resolve conflicts for whichever isn't merged first.

[ralfhandl]

Minor nits