Fix panic due to string slicing at char boundary

[ginnyTheCat]

This is a alternative solution to fix #2953 than #3024 by continuing to just support ASCII but not panic in this unwanted case.

Since this only makes code that didn't compile before compile now I would not consider this a breaking change.

[afurm]

The apply_to_field path returns pascal directly when the first character slice is empty, but doesn't this mean an empty string input returns itself rather than applying any transformation? It would be worth adding a test case for an empty string field name in apply_to_field to match the apply_to_variant coverage.

[ginnyTheCat]

I'm confused what transformations you would want to apply to a empty string? But yes, I'm open to a adding a test case ofc once I better understand your intentions.

[afurm]

The implementation mirrors --glob-case-insensitive cleanly. On the design question in the PR body: keeping this opt-in is the right call. On case-sensitive filesystems (Linux), there are legitimate files named .HTML as distinct from .html, so --type html should NOT match .HTML by default. Opt-in preserves that guarantee.

[afurm]

Apologies — the previous comment was accidentally posted to the wrong PR. To continue the thread on this PR: consider the case where a struct field is renamed via #[serde(rename = "")] — an empty string is a valid rename target. Does apply_to_field("") pass it through as-is, or should it be treated as a no-op that falls back to default casing logic?