SolveSpace 2.0 used the height of 'A' (i.e. cap height) to determine
the reference height.
SolveSpace 2.1 completely broke that during transition to Freetype,
and used something more or less random, by using FT_Set_Char_Size
with units_per_EM.
SolveSpace 2.2 attempted to fix that, but also used something more
or less random, by using FT_Request_Size with "unit" values.
Turns out that Freetype actually doesn't have a concept of cap height
at all. It is possible to extract it from the TT_OS2 table that is
present in some TrueType fonts, but it is not present in Microsoft
fonts (the msttcorefonts ones), and for those Linux fonts in which
it is present it doesn't appear very reliable.
So instead, use the height of 'A' instead, like version 2.0 did.
This has the advantage that it is quite bulletproof, and also matches
exactly what the old files are measured against.
One downside is that fonts without an 'A' glyph would not render.
We can deal with that when it becomes a problem.
This is a bit slow, but more importantly creates a race condition
where e.g. a failing "normal" test will be overwritten by
a succeeding "normal_migrate_from_v20".
This shouldn't ever be a problem since saving dumps the entire
internal state, or is supposed to, at least.
In 2.0, the distance between the points in the TTF request specified
cap height. In 2.1, that was accidentally changed to some arbitrary
value near cap height instead, due to a 72pt factor mess-up.
This commit restores the old behavior.
