Add the ability to set feature flags

[czechboy0]

Motivation

For a few upcoming features, we'd like to stage them into the current stable version and try them out, to get feedback and iterate before we tag a new breaking version.

Some examples of breaking features that could benefit from this:

• multiple request and response content types
• improved OpenAPI -> Swift name mapping
• new currency types based on swift-http-types
• async request and response bodies

It would be great to stage these in gradually, and consolidate a few of them into shared breaking versions, to avoid too much churn.

Modifications

This PR adds the concept of feature flags on the generator. They can be set either on the CLI, or in the config file.

The idea is that the translator logic will later inspect the list of feature flags, and change behavior accordingly (not present in this PR).

Note that I had to already add the multipleContentTypes feature flag, as keeping the enum empty broke the build. But that's okay, feature flags should be introduced early in the development process of a feature anyway.

Result

Now adopters can optionally enable pre-release features, and we can get feedback and run experiments before tagging a new breaking version.

Test Plan

Manually tested, with a debugger, that the feature flags propagate through the CLI machinery all the way to the generator pipeline.