RFC: support widening enum types with string

**Is your feature request related to a problem? Please describe.**

We consider GQL APIs adding types to an `enum` as a breaking change. However, this opinion is not universally held. If a resolver once returns `"FOO"` and suddenly begins returning `"FOO" | "BAR"`, the return signature of the resolver, in the mathematical sense, has changed if the return type was enums, not a wide `string` type.

We base some return types off of these enum values, or do exhaustive typechecking. Our GQL partners like using enums, even though they _change_. If something _changes_ it is not a fixed value... but it is fixed for some unknown period in time. This prevents us from writing exhaustively checked code, because when we do gql codegen, suddenly we are missing exhaustive cases.

**Describe the solution you'd like**

For an enum that currently generates `type Foo = "Bar" | "Baz"`, support generating `type Foo = string` or `type Foo = "Bar" | "Baz" | string` (which is really just `string`, but nice in that it's offers docs on known minimally expected values

**Describe alternatives you've considered**

having the GQL team use `String` GQL types, which they are against doing.

- `futureProofUnion` types i expected to do this, but docs are a bit light, and it did not do this

**Additional context**

Different companies treat enum changes with varying degree of "breaking". From our perspective, it's objectively breaking, and treating it anything else is _unsafe_ behavior.