Address U. F. O. shortcomings.

This attempts to address a number of issues mentioned in #1653, specifically the dropping of version data, the changing of glif names, and the reversal of reference and anchor orders. It also enables layered U. F. O. output in certain limited contexts outside of the specification.

We need to be careful to avoid creating inconsistencies.

If we import a typeface that has these values defined, I assume that we would preserve them and never update them (at least automatically) from the current FontForge functions for computing those values.

If we emit values from those functions to U. F. O. when there is no value defined, we create a situation in which the file performs differently in FontForge after round-tripping through FontForge. Specifically, FontForge will generate values automatically from the actual glyph data the first time it exports to U. F. O., but will never update those values again if it reloads from a U. F. O.. We use a lot of non-invertible mappings like this for other formats, of course, but, since U. F. O. is a working format, I'm trying to treat it a little more carefully. (The flip side is that one can expect other software that reads a working format to be smarter than a TrueType previewer.) And we probably ought to do for S. F. D. whatever we decide to do for U. F. O. for that reason.

Instead of doing this, could we count on any other piece of software being able to compute the derived values as necessary thus allowing us to reserve these fields for user-crafted values? Can we ask a few other vendors how they handle this?