For consistency.

New API:
HB_BUFFER_FLAG_REMOVE_DEFAULT_IGNORABLES
hb-shape / hb-view --remove-default-ignorables

One more text-rendering-tests test passing.  Eleven failing.

So I can merge this to master...

Also makes hb-ot-shape call morx for now instead of GSUB... Just for testing.

This only counts recursions right now.  Good start.

Hopefully...
Fixes https://github.com/behdad/harfbuzz/issues/429

This should affect mark attachment in vertical text.  I have no font to test,
but this sounds the right order.

Noticed while debugging https://github.com/behdad/harfbuzz/issues/532

Fixes tests/shaping/tests/cluster.tests

Fixes tests/automatic-fractions.tests

Makes consumption easier.

The numbers for right-to-left scripts are processed also from right to
left, so the order of applying “numr” and “dnom” features should be
reversed in such case.

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

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]

This reverts commit 69f9fbc4.

See https://github.com/behdad/harfbuzz/issues/347#issuecomment-268873401
Fixes https://github.com/behdad/harfbuzz/issues/347

Shape-plan caching is not implemented.

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.

New API:
- hb_font_get_nominal_glyph_func_t
- hb_font_get_variation_glyph_func_t
- hb_font_funcs_set_nominal_glyph_func()
- hb_font_funcs_set_variation_glyph_func()
- hb_font_get_nominal_glyph()
- hb_font_get_variation_glyph()

Deprecated API:
- hb_font_get_glyph_func_t
- hb_font_funcs_set_glyph_func()

Clients that implement their own font-funcs are encouraged to replace
their get_glyph() implementation with a get_nominal_glyph() and
get_variation_glyph() pair.  The variation version can assume that
variation_selector argument is not zero.

This better emulates Unicode grapheme clusters.

Note that Uniscribe does NOT do this, but should be harmless with most clients,
and improve fallback with clients that use HarfBuzz cluster as unit of fallback.

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

Right now the position_finish_advances() is empty.  To be used for
spacing attachments proposal later.

Is confusing.  I already hit it myself.  Remove.  We can optimize
ASCII based on Unicode properties.  But should not do based on
assumptions on the font.

This was brorken earlier, though, it's really hard to notice it.
Unlike the glyph_h_origin(), an unset glyph_v_origin() does NOT
mean that the vertical origin is at 0,0.

Related to https://github.com/behdad/harfbuzz/issues/187