Add more defcon compatibility APIs for better interoperability

[benkiel]

ufoLib2er's: noticed this:

https://github.com/googlefonts/ufo2ft/blob/2712e023567d6cc407bc1569da5fb3867d8fb970/Lib/ufo2ft/filters/sortContours.py#L38-L42

Is there a functional reason for ufoLib2 to not be following the established defcon API here? I understand the defcon speed issue, just talking about the API in this case. Seems like ufoLib2 could add appendContour at the glyph level and one wouldn't need to be aware of edge cases like the above, and that would benefit all.

[madig]

I think it simply wasn't needed for compatibility before. I suppose it could be added. Cosimo also noted that I could be using pens to stay mildly more API agnostic. Hm.

[benkiel]

Just want to strongly voice that having ufoLib2 API compatible with defcon is a very good thing. It allows one two swap in/out depending on specific need, doesn't fragment the tool space, and is keeps a well understood way of working. If ufoLib2 wants additional features, that's great, but a baseline compatibility should be a goal of the project, imho.

[anthrotype]

I agree in general. In particular this appendContour could be easily added.
Less so with things like Font(path) (defcon) vs Font.open(path) (ufoLib2), given we use attrs data classes with their default constructors. But maybe we could think of some tricks.

[madig]

I think the Font.open can stay as is. There could be a ufoLib2.DefconFont function that hides the difference :)