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

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

See thread "an issue regarding discrepancy between Korean and Unicode
standards" on the mailing list for the rationale.  In short: Uniscribe
doesn't, so fonts are designed to work without it.

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.

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

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).

Adjust the list of marks before SARA AM that get the reordering
treatment.  Also adjust cluster formation to match Uniscribe.

With Wikipedia test data, now I see:

  - For Thai, with the Angsana New font from Win7, I see 54 failures out
    of over 4M tests  (0.00129107%).  Of the 54, two are legitimate
    reordering issues (fix coming soon), and the other 52 are simply
    Uniscribe using a zero-width space char instead of an unknown
    character for missing glyphs.  No idea why.  The missing-glyph
    sequences include one that is a Thai character followed by an Arabic
    Sokun.  Someone confused it with Nikhahit I assume!

  - For Lao, with the Dokchampa font from Win7, 33 tests fail out of
    54k (0.0615167%).  All seem to be insignificant mark positioning
    with two marks on a base.  Have to investigate.

Fixes all Tibetan failures.  All 180k of them!

Merges back Hangul into the default shaper.

In a new callback...  Currently unused by all complex shapers.

This is what old HB does.  Morever, fixes rendering with Win8 malgun
font.  The Win7 version doesn't compose with either Uniscribe nor HB,
but Win8 version works as expected, like Uniscribe, with this change.

Lets call Hangul done for now.

As reported by Jonathan Kew on the list.

That's not in the OpenType spec, but it's what MS and Adobe do.

Previously, we were NOT actually recomposing Hangul Jamo.  We do now.
The two lines in:

test/shaping/texts/in-tree/shaper-default/script-hangul/misc/misc.txt

Now render the same with the UnDotum.ttf font.  Previously the second
linle was rendering boxes.

We can also start applying OpenType Jamo features later.  At this time,
I have no idea how the 'ljmo', 'vjmo', 'tjmo' features are supposed to
work.  Maybe someone can explain them to me?

In preparation for Hangul shaper.