Support content vs schema on parameters

[karlvr]

Refer to karlvr/openapi-generator-plus-generators#12 and https://swagger.io/docs/specification/describing-parameters/#schema-vs-content

You can see in ParameterBaseObject that schema can be missing. Presumably expecting content:

    interface ParameterBaseObject {
        description?: string;
        required?: boolean;
        deprecated?: boolean;
        allowEmptyValue?: boolean;
        style?: string;
        explode?: boolean;
        allowReserved?: boolean;
        schema?: ReferenceObject | SchemaObject;
        example?: any;
        examples?: {
            [media: string]: ReferenceObject | ExampleObject;
        };
        content?: {
            [media: string]: MediaTypeObject;
        };
    }

Note also that in operations.ts that we can't handle it when defaultContent.schema === null whereas we should still indicate that there's a request body, with a content type, just that it has no schema.

It's seeming like it was a mistake to have CodegenTypeInfo spill into things like CodegenParameter ... yep, we need to remove extends CodegenSchemaUsage from anywhere that might not have a schema; CodegenParameterBase. It's just that I think?

[karlvr]

Partially implemented in f5c140e