Updating our handling of JSON Schema to be compliant against allowEmptyValue

[erunion]

This resolves some issues with how we're constructing JSON Schema with regard to empty default properties.

Previously when an empty default was added into a data schema, a bug would cascade up into @readme/api-explorer and our usage of @readme/oas-to-har and we'd create an API HAR of a payload consisting of empty strings.

Instead now, if a default evaluates to an empty string, and allowEmptyValue: true is present on that property, we'll let the empty value through, otherwise it'll get tossed.

• 🧰 Fixes to our construction of parameter and requestBody JSON Schema work to be compliant on allowEmptyValue. See https://swagger.io/specification/#parameterObject for details on the property.
• 🚧 Rewrites handling of common common parameters to make the code less obtuse and easier to maintain.
• 🌱 Added a shitload of JSON Schema unit tests.

[erunion]

Renamed this from pathParameters to operationParameters because in the context of what this is doing, it's building up an array of every parameter on the option; not an array of every path parameter on the operation.

_{i spent a good amount of time trying to hunt down some weird edge cases when writing tests before realizing this is what was going on 🙃}

[erunion]

@rafegoldberg @gratcliff This is good for review.. Happy to go over it with you if you've got questions about WTF this is.

[gratcliff]

@jon It's hard to review this without knowing exactly what the outcome of the data transformation should look like.

There don't appear to be any glaring issues - data checks are present so nothing should fail. There is a lot of iteration and the recursion scares me a tad, but overall I think that's a necessity with the schemas you're trying to process.

[rafegoldberg]

Like Gabe said, a bit tricky to logic through some of this data transformation stuff. But yeah, code looks solid; I'm good on this!