Feature request: configurable CJK word motion strategy for w/e/b operations

Is your feature request related to a problem? Please describe.
When using VSCodeVim with Chinese text, motions like w, e, and b treat a long run of CJK characters as a single word.

For example, with text like:

hello你好world世界                                                                                                              
                                                                                                                                
or                                                                                                                              
                                                                                                                                
中文输入测试 

w / e may jump across the entire CJK run instead of stopping at smaller boundaries.

This is especially noticeable because VS Code itself can provide much better CJK word navigation when
editor.wordSegmenterLocales is configured, for example:

"editor.wordSegmenterLocales": ["zh-CN"]                                                                                        

But that setting does not seem to affect VSCodeVim motions.

Describe the solution you'd like
I would like VSCodeVim to support a configurable word motion strategy for CJK text.

For example, something like:

"vim.wordMotionStrategy": "legacy"

Possible values could be:

• legacy: keep the current behavior
• cjk-single-char: treat CJK characters as singleton motion units, so motions no longer skip across long CJK runs
• locale-segmenter: use Intl.Segmenter(..., { granularity: "word" }) when available, optionally informed by locale settings

I think making this configurable is important, because it changes motion semantics and different users may prefer different
behavior.

Describe alternatives you've considered

1. Keep using the current behavior
   This preserves existing Vim-like behavior, but it is not very usable for Chinese/Japanese text because an entire CJK run is
   treated as one word.
2. Use a lightweight CJK-only patch
   A smaller change would be to stop treating consecutive CJK characters as a single word and instead move one character at a
   time. This would already solve the “jump too far” problem, even though it would not be true word segmentation.
3. Use locale-aware segmentation
   A more complete solution would be to use Intl.Segmenter for word motions, which would be closer to VS Code’s native behavior
   for CJK text. This is more powerful, but also more complex and may diverge more from traditional Vim semantics.

Additional context
From reading the source, it looks like VSCodeVim currently implements word motions internally rather than delegating to VS
Code’s editor word navigation.

In particular, w / e / b appear to use the plugin’s own motion logic, and the current implementation groups consecutive CJK
ranges together. That seems to be why editor.wordSegmenterLocales does not affect these motions.

Because of that, a configurable strategy seems like the safest path:

• preserve current behavior by default
• allow a better experience for CJK users
• make it possible to start with a small patch and evolve later if needed

Start by locating VSCodeVim’s internal implementations of the w, e, and b motions and inspect how consecutive CJK ranges are grouped. Define the configuration and its supported strategies before changing behavior; done means the default preserves legacy motion, while the selected CJK strategy changes navigation as documented.