Fix edge cases: Unicode support and UpperIndicator logic

[google-labs-jules]

This PR addresses several edge cases in the strings2 library.
It introduces a new test suite edge_cases_test.go covering scenarios like Unicode mixed-case strings, conflicting options, and UpperIndicator behavior.
The splitMixCase function has been updated to use unicode.IsUpper, enabling correct splitting of Unicode strings.
The UpperIndicator logic in ToFormattedCase has been fixed to respect the indicator as a delimiter override when provided, resolving a bug where it was ignored unless matching the delimiter.

---

PR created automatically by Jules for task 9256443307798647680 started by @arran4

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[arran4]

@jules these are a little bit weird in terms of their interpretation of the intermediate langauge / representation. Which I guess it's what I asked for but can you reason on these for a bit longer Such as

		input := []Word{ExactCaseWord("helloWorld")} // ASCII works

Is by the IL a single word ,but the test tests to see if it's broken (when we aren't parsing from what I can tell.)

		if res != "hello-World" {

[google-labs-jules]

You are correct that in the Intermediate Language (IL), ExactCaseWord("helloWorld") is treated as a single word unit. However, OptionMixCaseSupport is explicitly designed to post-process these units, splitting them based on casing (effectively bridging the gap for mixed-case input that is passed as a single atom).

The test verifies that this intended splitting behavior works correctly. Previously, it worked for ASCII but was 'broken' (failed to split) for Unicode uppercase characters. I have added comments to the test to clarify that OptionMixCaseSupport is what drives this splitting behavior, even for single IL words.