In ten years we never used them...

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

New approach to fix this:
https://github.com/behdad/harfbuzz/commit/69f9fbc4200442a35484d3c790ae8f4979be5d60

Previous approach was reverted as it was too broad.  See context:
https://github.com/behdad/harfbuzz/issues/347#issuecomment-267838368

With U+05E9,U+05B8,U+05C1,U+05DC and Arial Unicode, we now (correctly) disable
GDEF and GPOS, so we get results very close to Uniscribe, but slightly different
since our fallback position logic is not exactly the same:

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

Bending to clang warnings...
https://bugs.chromium.org/p/chromium/issues/detail?id=593057

See thread at:
https://lists.freedesktop.org/archives/harfbuzz/2016-February/005462.html

The DEFAULT naming wasn't helpful, so just remove it.

Fixes assert fail in https://github.com/behdad/harfbuzz/issues/161
with libharfbuzz-fuzzing.

Unused currently.  To be used for Syriac stretch implementation.

https://github.com/behdad/harfbuzz/issues/141

Borrowed from https://bugzilla.mozilla.org/show_bug.cgi?id=1215411

Simplifies hb_in_range() calls as the type can be inferred.
The rest is obsessiveness, I admit.

No shaper has more than one behavior re this, so no need for a callback.

This reverts commit d5bd0590.

The reasoning behind that logic was flawed and made under
a misunderstanding of the original problem, and caused
regressions as reported by Jonathan Kew in thread titled
"tibetan marks" in Oct 2013.  Apparently I have had fixed
the original problem with this commit:

  7e08f125

So, revert the faulty commit and everything seems to be in good
shape.

See:
http://lists.freedesktop.org/archives/harfbuzz/2013-April/003101.html

Mozilla Bug 873902 - Display Arabic text with diacritics is bad
https://bugzilla.mozilla.org/show_bug.cgi?id=873902

Before, we were zeroing advance width of attached marks for
non-Indic scripts, and not doing it for Indic.

We have now three different behaviors, which seem to better
reflect what Uniscribe is doing:

  - For Indic, no explicit zeroing happens whatsoever, which
    is the same as before,

  - For Myanmar, zero advance width of glyphs marked as marks
    *in GDEF*, and do that *before* applying GPOS.  This seems
    to be what the new Win8 Myanmar shaper does,

  - For everything else, zero advance width of glyphs that are
    from General_Category=Mn Unicode characters, and do so
    before applying GPOS.  This seems to be what Uniscribe does
    for Latin at least.

With these changes, positioning of all tests matches for Myanmar,
except for the glitch in Uniscribe not applying 'mark'.  See preivous
commit.

WinXP doesn't include it.

As explained here:

  http://linux.thai.net/~thep/th-otf/shaping.html

Our output now matches Uniscribe for old fonts (eg. XP Tahoma) with no
Thai GSUB table.

Had to do some refactoring to make this happen...

Under uniscribe bug compatibility mode, we still plit them
Uniscrie-style, but Jonathan and I convinced ourselves that there is no
harm doing this the Unicode way.  This change makes that happen, and
unbreaks free Sinhala fonts.

The merger of normalizer and glyph-mapping broke shapers that
modified text stream.  Unbreak them by adding a new preprocess_text
shaping stage that happens before normalizing/cmap and disallow
setup_mask modification of actual text.

Hookup some Indic data to it.  More to come.

If there is no GPOS, zero mark advances.

If there *is* GPOS and the shaper requests so, zero mark advances for
attached marks.

Fixes regression with Tibetan, where the font has GPOS, and marks a
glyph as mark where it shouldn't get zero advance.

Enabled for all shapers except for Indic.

Add a shaper class struct.

When we removed the separate Hangul shaper, the specific normalization
preference of Hangul was lost.  Fix that.  Also, the Thai shaper was
copied from Hangul, so had the fully-composed normalization behavior,
which was unnecessary.  So, fix that too.

Oops, thinko.

Uniscribe reorders U+0E3A to be after U+0E38 and U+0E39.  We do that by
modifying the ccc for U+0E3A.

Fixes the two remaining Thai failures (see previous commit).