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.

Should fix Windows build again.

Move out-of-class definitions of two methods to hb-static so they
are accessible in libharfbuzz-subset.

Clang is being really peculiar.  Fix with:

-  inline hb_blob_t *sanitize (hb_blob_t *blob) { return c->sanitize<Type> (blob); }
+  inline hb_blob_t *sanitize (hb_blob_t *blob) { return c[0].template/*clang idiosyncrasy*/sanitize_blob<Type> (blob); }

Fixes #1105.

This new API returns cvXX and ssXX related NameId, things like
featUiLabelNameId, featUiTooltipTextNameId, sampleTextNameId, ... of cvXX
and UINameId of ssXX, in a unified way.

However HarfBuzz currently doesn't expose an API for retrieving the actual
information associated with NameId from the `name` table and that should be
done separately.

It had interesting stuffs like EXE parsing and
big-endian parsers but added in an attempt to find
a solution for #681 which later found not related.

We are not going to use them, at least in the foreseeable future

Previously the idea was to cache sanitize results externally (think,
in Fontconfig) and avoid resanitizing every time.  That's, not a good
idea.