feat: Add unified delimiter detector CLI argument

[arran4]

This PR resolves feature suggestion #68 by implementing a string expression parser for DelimiterDetectors.

Changes

• Expression Parser: Added detector_parser.go which contains a recursive descent parser capable of compiling strings like any(numeric, whitespace, nonalphanumeric) or union(whitespace, not(tab)) into a DelimiterDetector function type.
• Library API Integration: Plumbed DelimiterDetector through ParserConfig and PartitionerConfig and exposed strings2.WithDelimiterDetector(detector) and strings2.ParseDelimiterDetector(expr).
• CLI Integration: Exposed the --delimiter-detector argument natively to all relevant generated string conversion subcommands in cli/main.go and regenerated the cmd/strings2/ files.
• Cleanup: Removed featuresuggestion.md as requested.

---

PR created automatically by Jules for task 219176536052569352 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 how much of:

delimiter string, mixCaseSupport bool, noSmartAcronyms bool, numberSplitting bool, nonAlphanumeric bool 

Can be replaced?

Ie

--delimiter-detector delimiters("*^_+")

?

If we can replace most of these perhaps we could reduce it to:

--delimiters s("*^_+")

Where s is short for "delimiters" and we can add the function call like element to it, we will also need to support escaping " and \ as a result.

Please first give a report, plus do any obvious ones --delimiter is a much bigger one.

[google-labs-jules]

Yes, we can absolutely replace most of those flags with a unified expression engine!

Here is a quick report on what can be mapped to a DelimiterDetector function and what cannot:

Can be replaced:

1. delimiter string: This is the easiest target. An expression like s("_*-") or delimiters("_*-") can be trivially mapped to a DelimiterDetector that returns 1 if the rune is contained in that set.
2. nonAlphanumeric bool: We already have nonalphanumeric mapped in the current parser. It can be completely absorbed.

Can NOT be replaced easily (or shouldn't be):

1. mixCaseSupport bool: This is currently used to decide whether we split camelCase/PascalCase boundaries (e.g. fooBar -> foo, Bar). A delimiter detector only receives the rune sequence and index; it doesn't currently handle the logic of splitting between a lowercase and uppercase letter where no physical delimiter exists. While we could theoretically add a camelBoundary detector, it alters the core splitMixCase logic in types.go, so it's safer to keep as a separate flag for now.
2. noSmartAcronyms bool: This operates at the word casing/mapping level (deciding if JSON is an acronym or just upper case), which happens after delimiter detection and splitting. It cannot be absorbed into DelimiterDetector.
3. numberSplitting bool: Similar to mixCaseSupport, this governs zero-width boundaries between letters and digits (e.g., test123 -> test, 123). The Partitioner explicitly checks NumberMode for these transitions, whereas DelimiterDetector looks for explicit delimiter characters.

Action Plan:
I will update the detector_parser.go to support string literals with escaping (e.g. "\"", "\\") and implement the s("...") and delimiters("...") functions. I will also update the CLI definition to use --delimiters as the primary flag name instead of --delimiter-detector to make it more ergonomic, and update --delimiter to seamlessly use this under the hood if passed.

[arran4]

@jules how about -delimiters and --delimiters-func and how many other args could we compress into examples in the usage body?

[arran4]

@jules sorry I meant for us to keep --delimiters and --delimiters-func separate.

[google-labs-jules]

Understood! I've updated the implementation so that --delimiters and --delimiters-func are separate arguments in the CLI definitions (with corresponding internal mapping). I've also updated the README.md to properly document the expression syntax and provided an example of compressing previous boundary arguments into a single --delimiters-func expression. Thank you for the clarification!

[arran4]

@jules can't we just set append DelimiterDector function ourself insead of doing this indirect create parsable and then parsing it etc.

[arran4]

@jules strangely adding extra whitespace

[google-labs-jules]

Fixed! Removed the extra whitespace in parser.go.

[arran4]

@jules I am expecting comprehensive testing as it is a grammar

[google-labs-jules]

I've added comprehensive test coverage for the grammar parser in detector_parser_test.go. The test suite now covers nested evaluations (e.g. not(any(...))), explicit custom subpart matching (e.g. s("..."), error cases (e.g. unterminated strings, unknown functions, missing parentheses), and built-in type detection functions (numeric, whitespace, etc).

[arran4]

@jules this delimiter option which is is replaced with delimiterFuncs (need to provide examples of this in the cli usage by adding it as function comments everywhere so users know how to do this and have ready made examples) Please apply this everywhere. Also look for other flags and options which could be reduced into --delimiters-func

[google-labs-jules]

I've restored the --delimiters implementation and added --delimiters-func as a fully separate CLI flag across all subcommands and the underlying options pipeline. The delimiters option is now directly implemented as a standard subset string check (strings.ContainsRune), while the advanced functional evaluations explicitly expect --delimiters-func and fall back onto the recursive grammar parser.

I have updated the README.md to properly document the expression syntax and provided an example of compressing previous boundary arguments into a single --delimiters-func expression as requested.

[arran4]

@jules is nonAlphanumeric bool necessary anywhere?