Since add_int and cas are both read-modify-write, I wonder if we
also need a barrier after them.

Originally, glib's atomic_get was implemented as "memory_barrier; load".
I copied this into cairo, fontconfig, and harfbuzz.  However, that's
wrong.  Correct way is "load; memory_barrier".  The details are long
and hard to fully grasp.  Best to read:

  https://www.kernel.org/doc/Documentation/memory-barriers.txt

Also see my report against GNOME:

  https://gitlab.gnome.org/GNOME/glib/issues/1449

Note that this is irrelevant if C++11-like atomic ops are available.

To help TSan and be more "correct".

Although, all implementations just elevate that to ACQUIRE.
But requirement for us is just CONSUME.

This reverts commit b1e5650c.

After lots of head-scratching and finally finding the only truly
readable source to be the good old:

  https://www.kernel.org/doc/Documentation/memory-barriers.txt

I've convinced myself that we need consume memory-ordering on get().
The location of memory-barrier in a load should be after, not before
the load.  That needs fixing.  I'll do that separately.

When collecting all codepoints in the cmap avoid using large amount of memory for fonts that declare coverage over all 32 bit integers.

Add the fuzzer test case for feature collection timeout.

This is much faster then calling a bunch of individual add()'s.

Oriya went down from 9 to 2.

BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707311 out of 707394 tests passed. 83 failed (0.0117332%)
GUJARATI: 366355 out of 366457 tests passed. 102 failed (0.0278341%)
GURMUKHI: 60729 out of 60747 tests passed. 18 failed (0.0296311%)
KANNADA: 951300 out of 951913 tests passed. 613 failed (0.0643966%)
MALAYALAM: 1048136 out of 1048334 tests passed. 198 failed (0.0188871%)
MYANMAR: 1115830 out of 1123883 tests passed. 8053 failed (0.716534%)
ORIYA: 42327 out of 42329 tests passed. 2 failed (0.00472489%)
SINHALA: 271596 out of 271847 tests passed. 251 failed (0.0923313%)
TAMIL: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)

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

Note that there's minor positioning differences, and ONE reordering
difference between what we get for these and what Uniscribe gets.
Probably same as what's described in commit message for
1a96cc82

Probably not what Uniscribe does, but good idea?

This makes test suite happy again (at 44) while fixing the sequences
we were fixing, which were the following with KhmerUI.ttf:

  U+1789,U+17BC
  U+1789,U+17D2,U+1789
  U+1789,U+17D2,U+1789,U+17BC

Fixes rest of https://github.com/harfbuzz/harfbuzz/issues/974

Part of https://github.com/harfbuzz/harfbuzz/issues/974

Khmer spec has only one reordering phase, and only simple prebase
matra and Coeng-Ro reordering.  Implement that.  Specifically,
this was done to address recognizing different orders of the matra
and Coeng-Ro sequence.  That said, some combinations are now
reordered differently from Uniscribe.  Not clear if that's intended
or a bug in Uniscribe.  The following two sequences render the same
in Uniscribe whereas we reorder them differently:

  U+17A0,U+17D2,U+179A,U+17C2
  U+17A0,U+17C2,U+17D2,U+179A

For that reason, our test suite numbers regressed slightly.  Used
to be at 34 for fails, now at:

KHMER: 299080 out of 299124 tests passed. 44 failed (0.0147096%)

But generally a good change, and removed lots of code.

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

We only use it before cmpexch, so relaxed is fine and faster for
common case.

Indic shaper uses many stages.  Now we are provably not limiting
functionality whereas the previous limit of 8 was assuming real-world
practices.

Unused so far.

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

Prevents O(n^2) run times.

Should fix bots again.