To remove custom null object next..

We never rely on that being equal to readonly.  Just not being
writable.  Maybe not even that given that the object is inert.

In prep for next commit, using default null pool.

Use in a couple of places.  Push to bots to see how many unhappy before
I convert the rest.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11312
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11305

Follow up on b4c61130

Fixes https://github.com/harfbuzz/harfbuzz/issues/1374

Fixes https://github.com/harfbuzz/harfbuzz/issues/1374

But fix UBSan complaint.

There's nothing in hb_bytes_t that guarantees lexical ordering, and
ordering by length first is much faster.

Ouch!

[colr/feat/trak] minor

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11327

Reported as https://github.com/noporpoise/sort_r/issues/7

https://github.com/harfbuzz/harfbuzz/issues/1374

Hook AAT's lcar to _get_ligature_carets

A starting point, its sanitization is not tested however

I think it makes sense to accumulate it, but Ned tells me that's
what CoreText does.

Vastly improve kern/kerx tables, including cross-stream "kerning"

Let the fuzzing bots rip this code apart...

Finally:  Fixes https://github.com/harfbuzz/harfbuzz/issues/1356

Test case:
$ ./hb-shape GeezaPro.ttc -u U+0628,U+064A,U+064E,U+0651,U+0629
[u0629.final.tehMarbuta=4+713|u064e_u0651.shaddaFatha=1@0,-200+0|u064a.medial.yeh=1+656|u0628.initial.beh=0+656]

The mark positioning (kern table CrossStream kerning) only works if deleted
glyph (as result of ligation) is still in stream and pushed through the
state machine.