Improve DelimiterCase

[filipw01]

I made some changes that pass more test cases than the current solution. I was heavily inspired by CamelCase implementation

Let me know if this is something worth investing more time into or if I'm doing some basic mistake and butchering performance for example

Also, what should be the behavior of string1 conversion

• hello123 - this is the current behavior
• hello_123 - another valid behavior
• either one customizable with an option object like camelCase - in that case there's still a question of what should be the default (most likely hello123 for backwards compatibility)

Opinions seem to be mixed from one library to another

Even more interestingly, those libraries that default to hello_123 don't have an option to customize it, but those that default to hello123 have optional parameters to change that

Related issues:
#223
#336

What I'd still like to add:

• add more test cases for other cases (kebab-case etc.)
• decide what to do with the hello123 case and implement

[filipw01]

@voxpelli Could you take a look? At the moment I just want to know if this is something I should dig deeper into

[voxpelli]

@filipw01 Its not immediately obvious to me what the improvements are, and my experience with these helpers has been that they easily turn into a game of whackamole – any improvement reveals a couple of regressions.

I do see that you ultimate refer to my wish to unify the two: #224 (comment)

To support this use case I think we essentially would have to merge the functionality of the two. I can't remember why I didn't do that initially.

But that was ultimately solved through a new option instead: #501

I guess my main feedback would be to split this PR into more commits and try to make it as clear what and why the changes made are made, so that one can as easily as possible follow the reasoning in a review