Support wider range of chars in param names in codegen

[hughsimpson]

It's common to have openapi specs where a parameter or path contains characters that aren't legal in scala val names (e.g. path = member/{user-uuid} or operationId = get-member). This is a minor change that supports a much wider range of openAPI input without changing generated endpoint names too much - all non-legal identifiers are stripped of non-legal chars and converted to camelCase with illegal chars constituting a 'break'. Any legal identifier (as specificed by e.g. operationId) will be retained as-is - that is, we only rewrite the endpoint names where they would otherwise be illegal.

[adamw]

I guess this is exclusive with #3060?

[hughsimpson]

It would certainly produce merge conflicts (although I don't mind resolving them at all). I can see how both might be useful together though (e.g. if operationId=some-kebab-case-name, or simply wasn't present on some operation object). If it came down to a straight choice between the two prs, however, I prefer #3060

[adamw]

So I'm wondering about this one, even if an operation's name/id has dashes or other symbols inside, maybe we should instead convert to the "Scala convention" that is camel case? I've never been a fan of the back-ticked names :)

[hughsimpson]

Well that would certainly make for more consistent-looking variable names 😂. Yes, I think that makes sense if the regex match fails. I'll make that change and fix conflicts, but will probably be a bit later on, now.

[hughsimpson]

Fiddled with it a bit - think it does what we want. AFK now but will push up a reformat or something to kick the tests if you don't get around to rerunning the hanged job before tomorrow morning or so.

Although TBH could be more aggressive here - not sure the first part is really relevant after this...

[adamw]

This looks good :) Restarted the build

[adamw]

Thanks again :)