Correct for (rare) bad tracking of previousIntersectionPoint

[skef]

The single E glyph in prevint.zip exhibits a problem with previousIntersectionPoint tracking in flatten.py:reCurveSubSegments(). This is a real example from a production font but unfortunately I haven't been able to generate other similar cases synthetically. (I tried less hard with this one because the fix seemed straightforward.)

Anyway, it appears that very rarely the previousIntersectionPoint is not on the segment handled next. This is a particular problem for the elif flatSegment[-1] == inputSegment.flat[-1] and flatSegment[0] != inputSegment.flat[0]: code, which will use that point as the start of the spline if it isn't None.

My added code just checks to see if the previousIntersectionPoint is actually on the current inputSegment and if not sets it back to None so that it won't cause problems.

[frankrolf]

I talked about this with @typemytype, and he was concerned that this commit might create unexpected scenarios for other high-profile users of this repository. He suggested checking back with @anthrotype – do you think you’d have some bandwidth for checking this update in your tools? Thank you :-)

[anthrotype]

Hey Frank, thanks for checking with me. To be honest, it's too hard for me to track all the potential unexpected changes that this patch may produce for fonts built with fontmake (where booleanOperations is still the default remove-overlap backend).
I can see that for the test font attached above the patch does fix a real problem. If @typemytype says this is safe to do in general, feel free to merge and cut a release, and we can always roll back if problems arise.