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.

Shouldn't be needed.  I have a hard time imagining this breaking any
legitimate use case.

Needed some rework of Extension table.  Hopefully I got it right, and
the new template usage doesn't break any compilers...

No functional change right now.

This makes a lot of code safer.  We only try modifying the object in one
place, after making sure it's safe to do so.  So, do a const_cast<> in
that one place...

Fixes https://github.com/behdad/harfbuzz/pull/51

Add buffer var allocation asserts to a few key places.

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

Normally if you want to, say, conditionally prevent a 'pref', you
would use blocking contextual matching.  Some designers instead
form the 'pref' form, then undo it in context.  To detect that
we now also remember glyphs that went through MultipleSubst.

In the only place that this is used, Uniscribe seems to only care
about the "last" transformation between Ligature and Multiple
substitions.  Ie. if you ligate, expand, and ligate again, it
moves the pref, but if you ligate and expand it doesn't.  That's
why we clear the MULTIPLIED bit when setting LIGATED.

Micro-test added.  Test: U+0D2F,0D4D,0D30 with font from:

[1]
https://code.google.com/a/google.com/p/noto-alpha/issues/detail?id=186#c29

Before we were just relying on the compiler inlining them and not
leaving a trace in our public API.  Try to fix.  Hopefully not
breaking anyone's build.

Patch from Jonathan Kew.

No functional change.

Shouldn't change behavior at all, but is faster / more robust.

Previously we only supported recursive sublookups with
ascending indices.  We were also not correctly handling
non-1-to-1 recursed lookups.

Fix all that!

Fixes the three tests in test/shaping/tests/context-matching.tests,
which were derived from NotoSansBengali and NotoSansDevanagari
among others.