[checkoutlinesufo] Hash is stale on first run when writing to default layer

[miguelsousa]

Later in the workflow this bug will cause makeotf to fail building fonts, emitting messages like this:
src glyph Aacute is newer than processed layer. programName: CheckOutlines

Steps to reproduce the problem:

1. Start with a UFO without a processedHashMap file. The UFO must contain a glyph that has overlaps or components.
2. Run the command checkoutlinesufo -e -w -q font.ufo

Result: Glyphs that had overlaps and/or components will now be flat; file processedHashMap will be created but the hashes of those glyphs are stale, as they represent the glyphs' original state.

Workaround: Run the command again; this will update those glyphs' hash.

I'll add a test case for this once the integration-tests branch is merged.

[miguelsousa]

I realized that there's actually a second bug: If the font has composite glyphs but no glyphs with overlaps, all works well. As soon as one glyph containing overlaps is added to the font, the issue described above starts happening, and the composite glyphs start being flatten (whereas they weren't before). The flattening of the composite glyphs is the second issue.

[cjchapman]

As I just mentioned in #284: it seems to me that there’s a fundamental problem with the way CheckOutlinesUFO and ufoTools currently interact, which is that ufoTools is doing all its hash calculations based on data in the UFO file on the disk, and changes to that UFO file don’t happen until CheckOutlinesUFO finishes its work and writes out the UFO file.