[go-experimental] Preserve capitalized acronyms in structure names

[bkabrda]

Currently an openapi model called e.g. EntityURL would have a structure generated with name EntityUrl. I think this is both against the intention of the spec author and it is also against Go naming recommendations. This PR fixes that to preserve the capitalized acronyms.

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@antihax (2017/11) @bvwells (2017/12) @grokify (2018/07) @kemokemo (2018/09) @bkabrda (2019/07)

[wing328]

I think #4900 aims to fix similar issue.

[bkabrda]

@wing328 yeah, it's similar. What's different is that my PR doesn't touch the existing stable Go client (because this change would break backwards compatibility) and I think my PR is much simpler and it addresses the root cause of this issue (the solution in #4900 feels more like a workaround).

Do note that this issue isn't present in e.g. Java client generator (or other generators that I've seen), so I think it doesn't need a solution on the level of DefaultCodegen. I'm not saying that the solution outlined in #4900 is wrong, I just think it might have a slightly different usecase.

[jimschubert]

I agree that #4900 seems more like a workaround. It also seems like it will break literally every client with something that looks like an initialism or acronym when the user may not have intended this. For projects with static analysis rules, it may trigger warnings about identifiers not matching casing rules. For example, if you take any of the Java/jvm clients and push them to sonarcloud, you'll get a ton of warnings.

I much prefer the approach in this PR, since rules around language supported capitalization should be left to the language/framework and not forced globally.