v3.2: Add in: "querystring" parameter location treating the entire query string as one chunk of content

[handrews]

NOTE: This change was tentativley approved for 3.2 a long time ago, then punted to 3.3 when we thought we'd need to defer larger data modeling changes to that release. However, several things have changed that makes this suitable for 3.2 now:

• All this really does is allow using the Encoding Object in a new place, which we are already doing with PRs v3.2 Respect encoding in all Media Type Objects #4559 and v3.2: Support ordered multipart including streaming #4589. We should really include all of the "use the Encoding Object in more places" changes in one release!
• We already decided to add the media type registry in 3.2, when at one point we weren't going to do that until 3.3
• I realized that limiting in: querystring to using content avoids all of the confusing problems of how to deal with the Parameter Object's style/explode/etc. in an environment where they do not make sense (and duplicate the fields in the Encoding Object)

---

• Fixes:
  • Support for arbitrary query strings #1502 (arbitrary query strings)
  • Supporting of one separate 'required' option for query parameters #2347 (re-using parameter schemas independent of required-ness)
  • How to disallow unknown query parameter? #2511 (disallow unknown query parameters, could be done with deepObject but now can be done while also using style/explode for individual parameters)
• Fixes as much as we can fix without someting much more drastic:
  • [Question] Extend/override properties of a parameter  #2026 (re-using with differing constraints- this is as much as we can solve this without going to Moonwalk)
  • Aliasing query parameters #2298 (aliasing- no special aliasing construct, but using $refs comes pretty close)
• Enables fix through registering a media type or defining an out-of-band format for use with in: querystring, content: {text/plain: {...}:
  • Are indexes in the query parameter array representable? #1501
  • How to describe urls with ordered indexed array? #1504
  • Support deep objects for query parameters with deepObject style #1706
  • Proposal: dotDelimited style for query serialization. #3084

---

This allows treating the entire query string as a single parameter, which for application/x-www-form-urlencoded results in it being handled exactly as request bodies of that media type are handled.

Only one in: "querystring" is allowed per operation, and if it is present, no in: "query" parameters are allowed.

The content field MUST be used for in: "querystring", as the style and related fields are handled in the Encoding Object.

This also includes a recommendation that implementors design media types for complex query string formats such as those defined by various frameworks, and register a procedure for supporting them in our media type registry. This is intended to address a slow but steady trickle of requests to support various complex and often contradictory query string formats.

• 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