feat: support multipart form data encoding

[abvthecity]

• parse encoding field from openapi
• introduce content-type field in openapi-ir, fern yaml-schema, and fern-ir
• plumb through encoding.contentType -> fern-ir

---

remaining steps:

• plumb through in FDR and UI

[dsinghvi]

@abvthecity because we don't want to affect all object properties I would create a separate file called InlinedObjectPropertySchema and leverage the TypeReferenceDeclarationWithContentType type.

Then HttpInlineRequestBodySchema can depend on the InlinedObjectPropertySchema instead.

[dsinghvi]

@abvthecity Is this as simple as a string value that the generator needs to append?

[abvthecity]

not exactly.
the content-type here can be a list of acceptable content-types, i.e. image/png, image/jpeg.

the sdk should be able to infer the content-type from whatever file is being provided.

for string values (application/json), however, i think most likely yes. it's less likely (but not entirely impossible) to have a mixed text types... like text/plain or text/xml as variants that a single form entry might accept.

[dsinghvi]

Beyond the comment about introducing a InlinedRequestBodyPropertySchema

1. @abvthecity can you update the docs for the Fern Definition (link)
2. Can we add a test for the OpenAPI parsing to make sure it works. You can use the existing fixture
3. Ideally a validation rule that make sure encoding isn't used unless it is a MultipartFileUploadRequest (something like this)