Investigate the applicability of the Eytzinger order to inversion list-based sets

[hsivonen]

Currently, icu_uniset stores sets as an inversion list and performs binary search on the list. Binary search accesses memory both forward and backward. The Eytzinger order orders array elements for logically binary-search-like search so that the accesses are forward-only. We should investigate if this order is suitable for inversion lists, i.e. if the mismatch situation gives enough information about whether the search key in inside or outside the set.

(AFAICT, this wouldn't solve the issue that the characters most commonly looked up from sets are ASCII, which tends to involve the maximum number of comparisons in binary search anyway.)

[sffc]

Discussion:

• @echeran - We support multiple backends for set data, so this can be an additive change
• @hsivonen - The sort is actually faster, based on evidence from Firefox
• @echeran - I assume that there's additional space to get the faster performance, like a space-time tradeoff?
• @hsivonen - This has no size overhead. It has the same length of array, but the items are arranged in a different order, so that binary search goes forward only
• @sffc - Is it faster because of cache locality?
• @hsivonen - Yes, and also because the reads are always going forwards, so the CPU can make more assumptions
• @sffc - I think we should explore this not only for CodePointInversionList but also in general for other binary search data structures like ZeroMap
• @echeran - We use binary search from the Rust standard library, so this deserves to be its own crate so that others can take advantage of it