OAI2-> OAI3: Fail if there is no produces provided for a path and the response has a schema/body

[timotheeguerin]

Should resolve the confusion this cause later in the pipeline: Azure/autorest#3680

This is however a breaking change(Not really used inside of autorest as it would just fail later in the pipeline, so if we don't care about that we can do this)

Alternatives:

• Just log a warning. Cons: Easy to miss
• Add a parameter to enable this feature

Also include a few cleanup(including some basic typing for OAI2 schema)

[daviwil]

I think we want it to fail in the pipeline because this is an issue that we can't resolve. I'm fine with it being a breaking change from that perspective. Is it possible this will be a breaking change for the TS library since we're changing typings on function signatures? Should we bump major version for that?

[timotheeguerin]

It is a different type but what is being used is an abstraction on top of the datahandle which doesn't involve this change.

export const convertOai2ToOai3Files = async (inputFiles: DataHandle[]): Promise<OaiToOai3FileOutput[]>

I think just bumping to 4.2 should be good