Sorry for the noise, downstream custom builders.  Please adjust.

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

Fixes https://oss-fuzz.com/v2/testcase-detail/5216838347653120
which is a stack overflow, not by way of infinite recursion, just
being deep.  That's disallowed anyway, so catch it as it happens,
not afterwards.

Such a headache that Windows defines UINT8, ...; Just prefix it.

The three "XXXXX"'s should be switched to false.  Doing that separately for ease
of bisecting...

Particularly hazardous if the second layer mixes forward and backward lookups.

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

Not all shapers code is updated to set this properly.
GSUB and Arabic shaper are updated.
GPOS and other shapers are NOT.

Fixes https://github.com/behdad/harfbuzz/issues/224

This reverts commit 69f9fbc4.

See https://github.com/behdad/harfbuzz/issues/347#issuecomment-268873401
Fixes https://github.com/behdad/harfbuzz/issues/347

Fixes https://github.com/behdad/harfbuzz/issues/363

Not hooked up to shaper yet.

Fixes https://github.com/behdad/harfbuzz/issues/253

Hopefully we got the logic right.

Previously we only synthesized GDEF glyph classes if the glyphClassDef
array in GDEF was null.  This worked well enough, and is indeed what
OpenType requires: "If the font does not include a GlyphClassDef table,
the client must define and maintain this information when using the
GSUB and GPOS tables."  That sentence does not quite make sense since
one needs Unicode properties as well, but is close enough.

However, looks like Arial Unicode as shipped on WinXP, does have GDEF
glyph class array, but defines no classes for Hebrew.  This results
in Hebrew marks not getting their widths zeroed.  So, with this change,
we synthesize glyph class for any glyph that is not specified in the
GDEF glyph class table.  Since, from our point of view, a glyph not
being listed in that table is a font bug, any unwanted consequence of
this change is a font bug :).

Note that we still don't get the same rendering as Uniscribe, since
Uniscribe seems to do fallback positioning as well, even though the
font does have a GPOS table (which does NOT cover Hebrew!).  We are
not going to try to match that though.

Test string for Arial Unicode:

	U+05E9,U+05B8,U+05C1,U+05DC

Before:		[gid1166=3+991|gid1142=0+737|gid5798=0+1434]
After:		[gid1166=3+991|gid1142=0+0|gid5798=0+1434]
Uniscribe:	[gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]

Note that our new output matches what we were generating until July
2014, because the Hebrew shaper used to zero mark advances based on
Unicode, NOT GDEF.  That's 9e834e29.

Reported by Greg Douglas.

Right now the position_finish_advances() is empty.  To be used for
spacing attachments proposal later.

...at compile time.

This is a fix on top of the previous issue fixed in
c917965b.

This was caught by "libFuzzer" testing.

Not functional change (expected!).

Fixes possible invalid read of two bytes.

Reported by Behzad Najjarpour Jabbari, Secunia Research.