need only build glyf (or CFF) + hmtx for sparse layer masters

[anthrotype]

currently, when designspace source descriptors have a layerName attribute, the ufo2ft.compileInterpolatable... functions will build a whole master font for them, including global such as hhea, OS/2, name, etc. which do not vary from the default UFO masters. This means varLib will attempt to use these to build, e.g., an MVAR.
These "sparse" or intermediate masters only differ from their associated "whole" master UFO for the layer, in which only glyph outlines and metrics are stored. Thus, ufo2ft should only build hmtx and glyf (or CFF) for these intermediate masters.

[anthrotype]

There is one problem though.
When building sparse masters for TrueType, we store the glyph names in the post table, so that varLib can later on pick glyphs with the same name across multiple masters and blend them together in a variable font.
However, we do not want that the post.underlinePosition and post.underlineThickness values from these sparse masters be used to compute deltas for the MVAR table; those values will be equal to the UFO master in which that sparse layer happens to be located, and that's certainly not the intention of the user to add intermediate masters for underline position/thickness as sideeffect of having intermediate masters for particular glyphs...

I chatted with @behdad and I suggested to use an unlikely magic number for post.underline{Position,Thickness}, both defined as FWord or int16 fields, that signals varLib that the values from that master are not meant to be used for generating the respective MVAR fields. I suggested the value 0x7FFF (or 36767 in decimal, which is the maximum value for a 16-bit signed integer), which would be almost impossible in real world, as it means that if these were real, the top of the underline would be positioned 36767 font units above the baseline, and the thickness would similarly be ridiculously big.
Behdad replied

I'm comfortable with the 0x8000 hack. Just document somewhere how the sparse masters should look like

(I had initially suggested 0x8000 or -36768, but I think 0x7FFF is even less likely than the latter)

I'm still a bit reluctant to add that hack, but I don't see other solutions really, if one wants to be able to read post glyph names from a sparse TTF master, while at the same time ignoring the post underline values for MVAR.