Allow CPT get_range() accept a value transformation fn as arg

[echeran]

In ICU's implementation of getRange() for a CodePointTrie, it allows an extra arg that is a function that transforms the trie values before computing ranges of code points sharing the same value (called ValueFilter in ICU4J, called UCPMapValueFilter in ICU4C). ICU uses this in various ways, such as for pulling out data for a single property out of a trie that efficiently stores data for multiple properties at once.

The port of getRange() in #1529 omits this argument, which returns the trie values as-is. Adding this functionality could have multiple benefits.

One thing that might need to be considered is the type of the transformation function arg (Fn trait?) and whether that has any implications (ex: FFI) that may have follow-on considerations.

@markusicu

[sffc]

What is the concrete benefit? You can already write

cpt.iter_ranges(v).map(|range| /* transform here */)

What is the advantage of changing it to

cpt.map_values(|v| /* transform here */)

Is there a performance benefit? What is it?

[markusicu]

Each time you enter the get_range() function it has to do one-time setup, like an expanded version of a trie lookup. Then it continues visiting code points individually and by blocks, taking measures to minimize lookup indexing and reading of trie data values.

If you supply it with a ValueFilter (really a mapper I guess but this is what it's called), then get_range() itself will coalesce adjacent ranges that end up with the same effective value, and will continue with the inner loop. If you filter & map on the outside, you get more get_range() calls, losing some of those optimizations.

[sffc]

Blocked on adding benchmarks. @echeran can you link an issue for the benchmarks?