SIGN IN SIGN UP

Arrange encoding information more clearly

Refactor this to put the rules for mapping Encoding Objects
to valules with the `encoding` field (which performs the mapping)
rather than having most of it in the Encoding Object (which should
focus on how to apply a single Encoding Object to a single value).

This notably takes the special handling of arrays as repeated
values out of the Encoding Object section (and the default
`contentType` field value table) and moves it to the Media Type
Object.  The Encoding Object behavior is now consistent for all
types, while the _mapping_ done by the `encoding` field handles
the special case.

The only change (as opposed to re-organization and re-wording)
in this PR is the addition of a default `contentType` of
`application/json` for array values, which in the context of
the existing behavior is only relevant for array values nested
under a top-level array.  Past OAS versions were silent on this
topic, and presumably it just does not come up much, but it was
a gap we should fill.

As dicussed in today's TDC call, we have increasing (and modern)
use cases for supporting `multipart/mixed` (which we previously
claimed to support but never did).  This refactor makes possible
future support easier by moving the array special case, which
is governed by the `multipart/form-data` RFC, out of the Encoding
Object (which needs to work with other `multipart` formats) and
places it with the `encoding` field (which is web form-format-specific).
H
Henry H. Andrews committed
f2879df2735e2043b967ab2d376f76bc8e64a28a
Parent: e511664