Support contextual anchors

[simoncozens]

See #910. This implements the *top (etc.) anchors with an embedded custom context, causing them to replace standard anchor positions in certain contexts. Tested fairly extensively on an internal font project, but:

• No test suite yet
• No mkmk handling yet

[simoncozens]

I have to be honest here and say I've done what I need to make my font project work, and if anyone actually needs this in glyphsLib they're welcome to take it over.

[khaledhosny]

I added a simple test and I think this is good enough to merge.

[anthrotype]

I haven't looked a the logic of this proposed ContextualMarkFeatureWriter because I don't know how this contextual anchors are supposed to work, but I am a bit worried that this might make it more complicated to maintain and debug the MarkFeatureWriter, as we would then have code scattered across multiple repositories. I don't mean to block this, I understand there is a need to implement this, but I wonder, would it be possible to activate this special writer only when the .glyphs source actually contains such contextual anchors, and otherwise use the vanilla markFeatureWriter in ufo2ft? I suspect the majority of projects don't make use of this specialized writer and thus do not need to, so to speak, incur this added "risk" of higher debugging/maintenance cost introduced by the default use of this glyhps-specific writer. Does it make sense?

[khaledhosny]

I haven't looked a the logic of this proposed ContextualMarkFeatureWriter because I don't know how this contextual anchors are supposed to work, but I am a bit worried that this might make it more complicated to maintain and debug the MarkFeatureWriter, as we would then have code scattered across multiple repositories. I don't mean to block this, I understand there is a need to implement this, but I wonder, would it be possible to activate this special writer only when the .glyphs source actually contains such contextual anchors, and otherwise use the vanilla markFeatureWriter in ufo2ft? I suspect the majority of projects don't make use of this specialized writer and thus do not need to, so to speak, incur this added "risk" of higher debugging/maintenance cost introduced by the default use of this glyhps-specific writer. Does it make sense?

I want to extend this mark feature writer to also filter out anchor that start with non-alphanumeric character (googlefonts/ufo2ft#175 and googlefonts/ufo2ft#510), and possibly more in the future since it is not ideal to impose Glyphs-specific anchor naming conventions on UFO files (where anchor naming conventions are lightly specified).