Implemented for Arabic, Hebrew, and generic marks.
Activated if no GPOS table present.

Users should #include <hb.h> (or hb-ft.h, hb-glib.h, etc), but
never things like hb-shape.h directly.  This makes it easier to
refactor headers later on without breaking compatibility.

We need this to set data on objects safely without worrying that some
other thread unsets it by setting it at the same time.

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.

Need to think more about it.

Now that vertical text works correctly, I'm doing a last round
modification of the font-funcs API to simplify.  Expect no more
changes around here.

Starting to get there, but not without yet another round of changes.

I think I know wheere to go now.

I like this API *much* better.  Implementation still incomplete, but
horizontal works.

Design not final yet, and in fact I'm going to change it immediately,
but this is an standalone change for itself.

We need to know whether the glyph exists, so we can fallback to
composing / decomposing.  Assuming that glyph==0 means "doesn't exist"
wouldn't work for applications like Pango that want to use different
"doesn't exist" glyph codes for different characters.  An explicit
return value fixes that.

Makes it clear that kerning is in visual order.

get_contour_point now takes glyph id before point_index.

get_kerning now takes a vector to fill-in.

Not quite useful just yet.

Will be adding font_funcs subclassing instead.

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 :-).

That correctly reflects the reference ownership transfer happening.

This was a bizzare piece of API that I inherited from cairo.  It has
been wrong adding them to cairo in the first place.  Remove them before
someone uses them!