Support schema for multipart requests

Currently, multipart bodies always create an API schema like this:

"content": {
  "multipart/form-data": {
    "schema": {
      "type": "string",
      "format": "binary"
    }
  }
}

In my dropshot API, my request handler accepts this multipart body and then extracts parts from it. I expect some parts to conform to some schema. e.g. "first part should be a Person, second part should be a Workplace". This is not captured at all in the schema that Dropshot generated above, but it is required by the actual endpoint implementation code I wrote.

But the OpenAPI spec supports using detailed schemas that explain each part's expected type. So in theory Dropshot could generate a more detailed schema that captures my expectations for each part.

As the person who originally added multipart support, this oversight is purely due to me being silly a few years ago, and I think this gap should be fixed.

Start by tracing how Dropshot currently generates the multipart request schema described in the issue, then compare that behavior with the linked OpenAPI multipart documentation. Done means the generated schema represents the expected type of each multipart part rather than treating the whole body as a binary string.