Specific word boundary settings for hyphen & underscore detection

This is a new request spawned from https://smartgit.userecho.com/communities/1/topics/1562-word-navigation-ctrlleftright-do-not-stop-before-and-after-every-space

Basically, word boundary has two modes based on:
Preferences > Low-level properties > styledtext.useOwnWordBoundaryDetection value

It affects both Ctrl+left/right navigation and double-click selection.

If true, SmartGit own detection is used

- stops at hyphens (not great for kebab-variables, but understandable for plain English compounded-words)

- skips underscores (good for snake_case variables)

- stops at left and right of spaces (annoying)

If false, system detection is used. For instance on Ubuntu 22.04 + Unity desktop I have:

- stops at hyphens (same as above)

- stops at underscores (may be annoying for snake_case variables when you don't want to edit them)

- stops only one at spaces (good)

In most cases I just want to navigate as fast as possible and skip underscores, stop only one at space and possibly stop at hyphens (e.g. in Python I don't use kebab-case so hyphens are just for compounded-words so it's ok to stop at them)

More granular options over how boundaries are defined would make it easier to get the navigation we want. They would only apply when styledtext.useOwnWordBoundaryDetection is true since otherwise system would take over.

Examples:

- styledtext.whenUsingOwnWordBoundaryDetectionStopOnceAtSpace (honestly I think this one should be true by default, and actually wouldn't even need an option to be false, not sure who would really use the "stop at left and right of space" case since in most cases you can just go to either side and press left/right)

- styledtext.whenUsingOwnWordBoundaryDetectionStopAtHyphen (currently true)

- styledtext.whenUsingOwnWordBoundaryDetectionStopAtUnderscore (currently false)

To be fair, if right now SmartGit's own boundary detection was "fixed" to stop only once per space it would be perfect for my setting, and there would be no need for options.

The options may be useful in different settings though.

You may survey other devs to decide whether a hardcoded change or full options (more time to implemented, but more flexible) is better.