Ouch, how did things ever work without this?!  The added test that has a
dot-reph as well as a pre-base reordering Ra perfectly demonstrates the
bug (tested with Nirmala font from Win8 for example).  Testing suggests
that Win8 shaper has the *exact* same bug / behavior that we used to
have.  Odd.

Keep the logic simple, easier to explain to font developers.

This is a followup to 56800027.
Looks like in the Latin shaper, Uniscribe zeroes all Unicode NSM
advances *after* GPOS, not before.  Match that.

Can be tested using DejaVu Sans Mono, since that font has GPOS
rules to zero the mark advances on its own.

Currently broken with Sanskrit 2003 font.

This reverts 167b625d.  It didn't
matter before, but that's going to change with next commit.

This essentially reverts 1d6846db,
but that commit is from way back when.  We should be better
following the spec order now again.

Ouch!

As reported by Jonathan, OS X has setmode() that is something other
than what setmode() is on Win32.  So, limit invocation to Windows
platforms only.

Instead of checking for compiler, check for platform.

The Myanmar shaper now respects the uniscribe-bug-compatibility
option too.

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.

Testing with "clusters" now on par with testing without them.  15
failures both.

Implemented as a hack for now.  Myanmar failures down from 23 to 15.

MYANMAR: 1123868 out of 1123883 tests passed. 15 failed (0.00133466%)

The remaining 15 cases are all where the syllable is wrong according to
the OpenType spec.  We insert dottedcircle.  Uniscribe fails to do that,
but it also fails to reorder the prebase-reordering medial-Ra.  So it
gets it wrong.

Myanmar failures down from 51% to 0.00204648%!

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

Before, when matching ligatures, we never skipping over base / liga
glyphs even if that was what the LookupFlags asked for.

Fixed now.  We carefully reviewed all instances of this, and tested with
Amiri as well as some Indic scripts, and are confident that this should
NOT break anyone's fonts.  It's also how Uniscribe does it, from what
we can tell.

In aticipation of upcoming changes.

Was breaking reph formation logic when the Ra is the only consonant.
Devanagari regression fixed.  Down to 57 failures again.  Ouch.

Before, for most scripts, we were not trying to recompose two characters
if the second one had ccc=0.  That fails for Myanmar where U+1026
decomposes to U+1025,U+102E, both of which have ccc=0.  However, we do
want to try to recompose those.  We now check whether the second is a
mark, using general category instead.

At the same time, remove optimization that was conflicting with this.

[Let the Ngapi hackfest begin!]

This reverts commit 01013a0f.

Conflicts:
	config.h.in

Same argument as previous commit.

This reverts commit fab7a71f.

Conflicts:
	src/hb-ot-shape-complex-indic-machine.hh

Keeping that generated file in-tree causes problems with processes like
tinderbox  that automatically fetch and build harfbuzz.  It's harder to
bootstrap harfbuzz now (as was previously), but I'm willing to give this
another chance and see how it goes.

As reported by Peter Breitenlohner:

I think this is a very bad idea because ENV is used to specify a startup
file to be read by some/all shells.

Thanks to Khaled for spotting it.

Now, it looks like this breaks Cygwin again.  Have to figure out what's
going on.

Looks like Cygwin / MSVC declare it that way, and it still works on
MinGW32 cross.