API additions:

	hb_segment_properties_t
	HB_SEGMENT_PROPERTIES_DEFAULT
	hb_segment_properties_equal()
	hb_segment_properties_hash()

	hb_buffer_set_segment_properties()
	hb_buffer_get_segment_properties()

	hb_ot_layout_glyph_class_t

	hb_shape_plan_t
	hb_shape_plan_create()
	hb_shape_plan_create_cached()
	hb_shape_plan_get_empty()
	hb_shape_plan_reference()
	hb_shape_plan_destroy()
	hb_shape_plan_set_user_data()
	hb_shape_plan_get_user_data()
	hb_shape_plan_execute()

	hb_ot_shape_plan_collect_lookups()

API changes:

	Rename hb_ot_layout_feature_get_lookup_indexes() to
	hb_ot_layout_feature_get_lookups().

New header file:

	hb-shape-plan.h

And a bunch of prototyped but not implemented stuff.  Coming soon.
(Tests fail because of the prototypes right now.)

To match upcoming API.

Avoids USHORT, SHORT, ULONG, LONG clashes with Windows API.

To be used in the next patch.

Fixes logic also, where before we were always matching if glyphs_len==1
and a ligature started with the glyph.

We need the font for glyph lookup during GSUB pauses in Indic shaper.
Could perhaps be avoided, but at this point, we don't mean to support
separate substitute()/position() entry points (anymore), so there is
no point in not providing the font to GSUB.

It was impossible to meaningfully use them from the outside these days.

Gives me a good 10% speedup for the Devanagari test case.  Less so
for less lookup-intensive tests.

For the Devanagari test case, the false positive rate of the GSUB digest
is 4%.

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.

I didn't like it from the beginning.

Untested.

Fixes issue reported by Khaled Hosny with his Hussaini Nastaleeq font
and sequences like those added in the previous commit.

I know...

Filling in.

Patch and description from Jonathan Kew:

It turns out that some legacy Thai fonts provide OpenType substitution
features to implement mark positioning, but (incorrectly) put those
features/lookups under the 'latn' script tag instead of using 'thai' (or
possibly 'DFLT'). See
https://bugzilla.mozilla.org/show_bug.cgi?id=719366 for an example and
more detailed description.

Although this is really a font bug, I suggest that we could improve the
rendering of such fonts by looking for the 'latn' as a fallback if
neither the requested script nor "default" is found in
hb_ot_layout_table_choose_script. Suggested patch against harfbuzz
master is attached.

This does _not_ affect the other kind of legacy Thai font, where custom
code to support vendor-specific PUA codepoints would be needed. I'm not
keen to go down that path; IMO, such fonts should be ruthlessly stamped
out in favour of standards-based solutions. :)

JK

Since we already switched to accepting -1 as 'zero-terminated'.