Wow, it took me a few days to find the right fix!

We now set the advance for attached marks to zero, but we
do this in the _finish() state of gpos, so it shouldn't
regress with fonts like DejaVuSansMono that explicitly
decrease the mark advance width to set it to zero.

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

I think I know wheere to go now.

Currently it only marks glyph origins.

The base for vertical is almost ready 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.

Apparently there exist systems with mprotect(), but not mmap()?

I'm in awe with how many bugs this test revealed.  All fixed.

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.

More portable.

Such that user_data and other finalizers cannot resurrect object

Test passing now.