[font] Tweak Cmap cache

[benoitkugler]

Thanks to @redawl investigation, I realized our current implementation is not optimal because it passes the Cmap cache array by value, forcing a copy, while passing a pointer is more performant (see pointer.txt column).

The new benchmark results are now also better when adding a cache for not supported runes (see not-found-cache.txt column).

There is a small cost to pay when the "not supported" cache is not hit, but it is small enough.

Closes #252

.	old.txt	pointer.txt	not-found-cache.txt
	sec/op	sec/op vs base	sec/op vs base
Cmap/latin_text-4	1004.5n ± 8%	122.5n ± 6% -87.81% (p=0.000 n=10)	145.1n ± 7% -85.55% (p=0.000 n=10)
Cmap/chinese_text-4	769.50n ± 4%	362.50n ± 3% -52.89% (p=0.000 n=10)	93.69n ± 8% -87.83% (p=0.000 n=10)
Cmap/mixed_text-4	1773.5n ± 3%	488.4n ± 3% -72.46% (p=0.000 n=10)	244.5n ± 3% -86.22% (p=0.000 n=10)
geomean	1.111µ	278.8n -74.90%	149.2n -86.57%

[whereswaldon]

Can we document that this cache performs best on sparse keys? It generates collisions for keys less than 256 values apart. That could be useful for implementing an LRU policy when using the cache (as I think we do), but it's not immediately obvious when looking at the implementation (I had to sit here for a while and work out how this cache could manage such a large keyspace with such small storage).

[benoitkugler]

Thank you, I have clarified the documentation and mentioned sparse keys.

[whereswaldon]

Thanks for tackling this! I have one non-blocking request for implementation docs, but the rest looks great.