To be used in the next patch.

To room for more allocations, coming.

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

See comments.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=437633

Start squeezing more out of lig_id/lig_comp.

This commit: a3313e54 broke MarkMarkPos
when one of the marks itself is a ligature.  That regressed 26 Tibetan
tests (up from zero!).  Fix that.  Tibetan back to zero.

This was broken as a result of 7b84c536.
As Khaled reported, MarkMark positioning was broken with glyphs
resulting from a MultipleSubst.  Fixed.  Test with the ALLAH character
in Amiri.

This is to incorporate it into GSUB/GPOS processing.

The GSUBGPOS part still missing.

As was reported to me, glib-mkenum does not understand named enums,
so remove for now.

gdb was showing <anonymous enum> instead of useful stuff, so name
all our enums.

hb_face_get_blob() renamed to hb_face_reference_blob(), returns a
reference now.

hb_face_[sg]et_index() added.

hb_face_set_upem() added.

Where causing issues for people with MSVC.

Needed to be able to include <Windows.h> from hb-object-private.h.

I was reconsidering whether y should grow down, since all three/four
times I've used this API I was tricked and got that wrong in my use.
So I was very inclined to make y grow down instead of up.  However,
considering that the font space has y up and it would be very confusing
for callbacks to work against that, I decided that what I really want
is for the user to be able to set y_scale to a negative number to imply
that user-space y grows down.

Changing x_scale/y_scale from unsigned int to int allows that, and I've
made pango to use that instead of negating glyph y_offset later.  hb-ft
however still has y group up.  I *guess* that's how FreeType works?
I'm not sure, FreeType docs don't make this clear...

I'm happy with the resolution :-).

So we can liberally use the simple features of C++ that parts of the
codebase is already using.