Improve snowball stemming by adding an insert-only cache

[costin]

Snowball stemming is expensive due to algorithmic suffix manipulation repeated identically for every occurrence of the same token.
This PR adds an small insert-only cache (CharArrayMap) to avoid the redundant work by exploiting the fact that natural text is Zipfian (same short words account for majority of token occurrences).
The cache is small (1024 entries, ~75KB) and caches only tokens up to 10 chars.
It is enabled by default to avoid mapping changes for existing users and can be disabled through maxCacheSize=0.

Benchmarks

AMD EPYC 7R32 (c5a.2xlarge), JDK 25, 500 unique words, 10K tokens Zipfian corpus. 3 forks, 10 iters × 1s. cacheSize=0 is the uncached baseline.

language	vocabSize	cacheSize=0	cacheSize=1024	speedup	cacheSize=4096	speedup	cacheSize=8192	speedup
English	500	277.9 ± 2.2	751.4 ± 4.0	2.70x	743.4 ± 6.9	2.67x	734.2 ± 7.6	2.64x
English	5,000	1,893	4,421	2.34x	4,526	2.39x	4,521	2.39x
English	50,000	1,882	4,366	2.32x	4,476	2.38x	4,488	2.38x
German	500	201.4 ± 1.3	550.2 ± 9.6	2.73x	555.3 ± 7.2	2.76x	551.7 ± 1.7	2.74x
German	5,000	1,773	4,163	2.35x	4,237	2.39x	4,222	2.38x
German	50,000	1,757	4,071	2.32x	4,159	2.37x	4,154	2.36x

The default cache size of 1024 entries was picked from the sweep above as it captures virtually all the benefits across English and German.

[dweiss]

I don't think it's worth the extra complexity, to be honest. If you have costly components in your indexing pipeline then there's another idea you can try - wrap the costly pipeline into a top-level component which then returns all the cached attributes for a surface token image. The "cache" here can be dumb and just clear itself when it saturates (which is much simpler than any "real" hit-count cache) and just rely on token distribution.

This works for everything (assuming context independance) and indeed can speed up processing... but it is something that users should/can configure themselves, knowing what their data and analysis pipeline is, I think.