Towards disabling ZWJ-skipping in certain GPOS contexts.

Part of https://github.com/flutter/flutter/issues/16886

Ouch.  How did we not hit this bug before...

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

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

I'm glad we have leak-detector bots now.

Decode the string as Python 3 returns bytes string, and also don’t
assume that it ends with a new line.

See also https://github.com/harfbuzz/harfbuzz/pull/1169

See also https://github.com/harfbuzz/harfbuzz/pull/1169

See also https://github.com/harfbuzz/harfbuzz/pull/1169

See also https://github.com/harfbuzz/harfbuzz/pull/1169

We reverse too many times. Can be optimized. But I doubt many fonts
use reverse lookups, so doesn't matter.

Other than not applying user features, this completes morx table
implementation.

Just speculation. Needs tests to determine which is correct behavior.

When building with the auto tools, the manually mantained
harfbuzz-config.cmake is installed. When building with cmake, we can use
cmake to generate the correct config files for us and install them.

Some clang versions define static_assert as a macro apparently, so we cannot
redefine it...

This reverts commit 94bfea0c.
This reverts commit 4e626278.

"Unused private member" warning turned error.  ugh.

So we don't accidentally break it again.

...like UnsizedArrayOf<>.

This fixes a class of crasher bugs, mostly with color and AAT tables.  We
cannot use nullable offsets to varsized data that does not declare min_size,
because it's nost safe to use our fixed-size null pool for types that have
their size external.  So, use non_null'able offsets for these.

A further enhancement would be to make use of min_size in Null<> itself.
Will try that after.

Does NOT apply user-selected features.  But at least now enables
correct subtables.

An offset to unsized arrayis not safe to be redirected to our fixed-sized
null pool.  Plus, we want to reject, not repair, bad-looking dfonts.

Not sure how I didn't add before...

Just to disagree with myself re being done with this code...

Previously, ResourceForkHeader was defined as 30 bytes, having the typeCountM1 as last member.
There was a mysterious offset-by-2 in the code, derived from FontTools and JDK code this was
ported from.

In testing, I observed that typeListZ offset is actually 28.  Suggesting that the typeCountM1
does NOT actually belong to ResourceForkHeader, but belongs to the array itself.  Adjusting for
that resolves the mystery +2 offset hack, so everything is clean and good now.

This, concludes my dfont hacking.  The code looks great now, and I'm happy to leave it.
Fuzzers might disagree though, we will see!

So it doesn't accidentally match our templates, etc.