[REQ] [swift5] Do not make String conform to CodingKey when there are no additionalProperties in the source spec.

[romanzhukovTB]

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

At the moment the swift5 generator produces a String extension that adds conformance to CodingKey. The problem is that when the generated library is imported into the host project, all of the extensions are imported automatically and there is no way to avoid that at the moment (eg. by using more specialized imports). This particular extension adds a couple of init methods that may be unwanted/confusing.
Consider this snippet for example:

let result = [1,2,3].map(String.init) // `result` is going to be an empty array, instead of ["1", "2", "3"]

If the library is imported, the compiler will interpret String.init as String.init?(intValue:) instead of the generic initializer provided by the Swift standard library. This may result in incorrect behaviour or other bugs, unless that piece of code is covered with tests.
I know, using something like String.init in this fashion is potentially dangerous and ambiguous in itself, however such code may pop up here and there.

Describe the solution you'd like

As far as I understand the main reason for this adding this protocol conformance to String is to enable encodeMap/decodeMap. However, if there are no additionalProperties defined for any type in the source OpenAPI spec, then perhaps this conformance is not needed.

Describe alternatives you've considered

As a workaround, manually removing this conformance for libraries generated from specs that don't contain additionalProperties in their types seems to work.

[sehajc]

I think the generator should provide opt-in extensions or not have extensions for types the framework doesn't own. Please see https://swiftindepth.com/2019-02-17/avoiding-extension-hell

[4brunu]

I created #9375 that fixes this issue