Difference in anchor propagation & GDEF classification for some glyphs in oswald

[cmyr]

So this is a funny issue that I will try my best to explain:

• Oswald has a bunch of non-spacing marks, like "acutecomb", "cedillacomb", etcetera.
• For (most, all) of these there is also a spacing equivalent, like "acute" and "cedilla". These spacing marks are what you would get if you just wanted to display an accent on its own, like ¨ or ˆ.
• For the majority of these pairs of glyphs, the non-spacing version has an outline and anchors, and the spacing version just has an outline (that is, there is no use of components)
• However for two of them (cedilla and hungarianumlaut) the spacing version uses the non-spacing glyph as a component.

This causes us to deviate from fontmake in how these two glyphs are treated for the purposes of mark lookup generation. The cause of this is kind of complicated, but to the best of my understanding:

• during anchor propagation, the python toolchain doesn't propagate the anchors from "cedillacomb" to "cedilla" (I haven't investigated exactly why)
• with no anchors, these glyphs don't participate in mark lookup generation.
• In fontc, we propagate these anchors, and then assign these glyphs to the base class (because they have a base anchors and are not combining marks)

The confusing part here is that glyphs.app itself seems to never treat non-combining marks as bases, which means that fontmake is matching glyphs.app, but for a different reason. (glyphs.app propagates the anchors but doesn't consider the glyphs to be bases; fontmake would consider the glyphs to be bases except that it doesn't propagate the anchors, so it's irrelevant.)

My best understanding right now, with some chat input from @simoncozens is that fontc is correct and these glyphs should be treated as bases if they have anchors, and they should get anchors during propagation, but my confidence in this matter is low.

[cmyr]

After conversation with @anthrotype we have agreed that glyphsLib should match the anchor propagation code in fontc (which itself is based on the source in glyphs.app). This will get fontc and fontmake output to match, and once we're there we can worry (or not) about whether we should be matching glyphs.app in whether or not we treat these glyphs as bases.

We'll reuse googlefonts/glyphsLib#368 to track rewriting the glyphsLib anchor propagation.