v3.2: (Split and smaller!) Support ordered multipart including streaming

[handrews]

**NOTE: This is just the new fields and their description, schema, and schema tests, with several things removed: 1.) the elaborate rules for determining type, which are now in PR #4743, 2.) the examples, which are in PR #4746 so they can be discussed in-depth and updated based on the pending Example Object changes. The contents of this PR are otherwise identical to #4589.

---

This adds support for all multipart media types that do not have named parts, including support for streaming such media types. Note that multipart/mixed defines the basic processing rules for all multipart types, and implementations that encounter unrecognized multipart subtypes are required to process them as multipart/mixed. Therefore support for multipart/mixed addresses all other subtypes to some degree.

This builds on the recent support for sequential media types:

• multipart/mixed and similar meet the definition for a sequential media type, requiring it to be modeled as an array. This does use an expansive definition of "repeating the same structure", where the structure is literally any content with a media type.
• As a sequential media type, it also supports itemSchema
• Adding a parallel itemEncoding is the obvious solution to multipart/mixed streams requiring an Encoding Object
• We have regularly received requests to support truly mixed multipart/mixed payloads, and previously claimed such support from 3.0.0 onwards, without actually supporting it. Adding prefixEncoding along with itemEncoding supports this use case with a clear parallel to prefixItems, which is the schema construct needed to support this case.
• There is no need for a prefixSchema field because the streaming use case requires a repetition of the same schema for each item. Therefore all mixed use cases can use schema and prefixItems

• schema changes are included in this pull request
• schema changes are needed for this pull request but not done yet
• no schema changes are needed for this pull request

[handrews]

The most recent commit slightly relaxes the wording around using Encoding Objects and makes it clear that if you have more Encoding Objects than properties or items, this is not an error (which I think is not a change, but it depended on how you read a certain MUST).

I also relaxed the requirement that the property MUST exist "in the schema" (presumably under properties) as this is supplanted by the schema search guidance in PR #4743, which notes that you can just validate the data and then work with its type/structure directly whenever that is possible.

[ralfhandl]

+1, minor nits

[handrews]

@ralfhandl updated - both concerns should be addressed now!