PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh, ./bin/security/{LANG}-petstore.sh and ./bin/openapi3/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
  @wing328 @kenjones-cisco @tomplus @Jyhess

Description of the PR

as described in #2165, the client doesnt handle well sending mixed-type multipart.

This PR adds support for the OAS3 encoding field that can be found in the requestbody in the case of a multipart type:
spect here, which is used to described the content type and headers of each multipart part (sic).

There is a possibility of multipart header parameters, because each multipart field can be added a headers property that can be varied by the caller, so I've added a multipartHeaderParams field that can be used for that.

I've implemented all this logic in the Python client. In the case of a multipart operation, instead of post_params being a list of simple (name, value) tuples, we can make complex cases by using urllib3 RequestField directly

field = RequestField(name, value, headers=headers)
field.make_multipart(headers.get('Content-Disposition'),
                                 content_type,
                                 headers.get('Content-Location'))

I don't have an API that necessitates the variable header thing, but the mixed Content-Type are working fine. When using parameters that are file, there still a bug the files are uploaded as string like
<filename>,b'<binary-data>', but it's related to previously reported issue #2118