x-www-form-urlencoded support and some formdata refactoring.

[devNoiseConsulting]

feat: adding x-www-form-urlencoded support
feat: form data encoding support
refactor: form data accumulator functions move to named functions
refactor: improving the mapFormData function

[joolfe]

Hi @devNoiseConsulting thanks for your support :-), I'm working in another feature but as soon as I finish this one I will review in deep the pull request for now I just have some comments:

1. The encoding field that you have added it not correct, you can check on https://editor.swagger.io/?_ga=2.261323918.2075431757.1627116347-1191844855.1621186828, the encoding field should be at same level as the schema but in this case I think is not too useful as if you read the OpenAPI spec say:

If the property is a primitive, or an array of primitive values, the default Content-Type is text/plain
That means for primitive types we should not inform the encoding as the spec already define that are text/plain and also say that
If the property is a type: string with format: binary or format: base64 (aka a file object), the default Content-Type is application/octet-stream
wich is exactly the case of the FIle types because we are already putting the type: string, format: binary so the specs say that this means encoding application/octet-stream. So for our use case we really don't need to create the encoding field in the OpenApi specs.

2. The require field that you have added is not correct, you can check on https://editor.swagger.io/?_ga=2.261323918.2075431757.1627116347-1191844855.1621186828, the require field in an object schema is a top level properties with an array of the required fields, I think that is a cool feature but is not worth to implement as is something that normally is ignored by the UI tools that use OpenAPI, I mean, normally they just print the schemas and in this case would be more useful to have an external schema that is a pending feature...