Leading/trailing separator characters leak into snake_case, kebab-case, and MACRO_CASE output (e.g. `_privateField` → `-private-field`)

[matt-edmondson]

What's wrong

In CaseConverter/CaseConverter.cs, ToMacroCase() (which ToSnakeCase() and ToKebabCase() chain off of):

output = input.Trim();

This only strips whitespace. Any leading/trailing non-alphanumeric character (_, -, ., etc.) survives the trim. NonAlphaNumericRegex().Replace(output, " ") then turns that leading/trailing character into a boundary space, which later gets converted straight into a leading/trailing _ (or -/uppercase equivalent) — the existing while (Contains("__")) loop only collapses doubled underscores, not leading/trailing ones.

ToTitleCase() (used by the Pascal/Camel path) doesn't have this bug because it calls CollapseSpaces(...).Trim() after the space substitution — the snake/kebab/macro path has no equivalent second trim.

Why it matters / concrete failure scenario

• "_privateField".ToKebabCase() → "-private-field" (leading hyphen), expected "private-field"
• "_privateField".ToSnakeCase() → "_private_field", expected "private_field"
• "_privateField".ToMacroCase() → "_PRIVATE_FIELD", expected "PRIVATE_FIELD"

Converting a leading-underscore field name (a very common C#/Python/JS private-field naming convention) to snake/kebab/macro case is a realistic, everyday input for a case-conversion library, and it currently produces output with a stray leading separator.

Suggested fix

Trim _/- (in addition to whitespace) from the space-delimited intermediate string before converting spaces to the target separator — mirroring what ToTitleCase() already does via CollapseSpaces(...).Trim().

Acceptance criteria

• "_privateField".ToSnakeCase() returns "private_field" (no leading _), and the equivalent kebab/macro conversions have no leading/trailing separator, for both leading- and trailing-separator inputs.