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

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

UCDN is not updated yet.

Towards fixing https://github.com/harfbuzz/harfbuzz/issues/667
The Khmer spec is different enough from other Indic ones to require
its own grammar.

No change in functionality.  Test numbers are:

BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
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%)
KHMER: 299071 out of 299124 tests passed. 53 failed (0.0177184%)
MALAYALAM: 1048136 out of 1048334 tests passed. 198 failed (0.0188871%)
ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%)
SINHALA: 271662 out of 271847 tests passed. 185 failed (0.068053%)
TAMIL: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)

In ten years we never used them...

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

Fixes joined Adlam rendering.

Fixes https://github.com/googlei18n/noto-fonts/issues/828

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]

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

With javatext.ttf, the reodering medial Ra gets its advance width
zero'ed in Uniscribe implementation, and the font adds the advance
back.  Our Indic shaper does not do that, but USE does.  So, route
Javanese through USE.  That's what Microsoft does anyway.  Test:

  U+A9A5,U+A9BA

This also seems to fix the following sequence, and variations thereof:

  U+A99F,U+A9C0,U+A9A2,U+A9BF

These are frozen, so good time to add.

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

Unused currently.  To be used for Syriac stretch implementation.

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

Same logic as Indic and SEA.

These were never tested with Indic shaper, and indeed wouldn't work there
because they didn't have their viramas and other config defined.  They are
all also supported by MS through USE, so route them there.

Don't reroute scripts that we were routing to other shapers
before (just yet).

This is to reflect the UTC decision to change the encoding model of
New Tai Lue from logical to visual to be similar to Thai, Lao, and
Tai Viet: http://www.unicode.org/L2/L2014/14250.htm#141-C26

The visual encoding is already the current practice of encoding New
Tai Lue on the web anyway:
http://www.unicode.org/L2/L2014/14195-newtailue.txt

Fixes behdad/harfbuzz#66.

Looks like Unsicribe responds to the 'mymr' tag by zeroing marks
GDEF_LATE instead of generic-shaper UNICODE_LATE.  Implement that.

Fixes
Bug 81775 - Incorrect Rendering with harfbuzz-ng myanmar unicode
https://bugs.freedesktop.org/show_bug.cgi?id=81775

Micro-test added based on Padauk.

Still needs update to joining table to fully work.

Now default shaper is truly no-op.

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

Not exhaustively tested, but I think I got the intended logic
right.

The logic can perhaps be simplified.  Maybe we should disabled
normalization with this shaper.  Then again, for now focusing on
correctness.

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

Both Indic and SEA seem to do it just fine, but SEA is much
simpler.

Rename HB_SCRIPT_CANADIAN_ABORIGINAL to HB_SCRIPT_CANADIAN_SYLLABICS
and a macro for the old name.

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

Handles Tai Tham, Cham, and New Tai Lue for now.

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.

Myanmar failures down from 51% to 0.00204648%!

MYANMAR: 1123860 out of 1123883 tests passed. 23 failed (0.00204648%)

See comments and discussion on the list.

So we can handle Sinhala split matras smartly...  Coming soon.