Extract BlueValues as Fixed rather than Int
After we addressed the "party baseline" bug last summer the reporting user indicated that the default location and some other points in design space rendered OK, but other points in design space still had problems. The most obvious issue being that the x-heights of lower-case letters did not align. See https://github.com/adobe-fonts/source-serif/issues/121#issuecomment-1773794136 , and here is an image from that comment: 
Note that the tops of glyphs with overshoot tend to be one pixel higher than those that are flat at the x-height.
After some analysis we determined that this was due to an interaction between BlueValue rounding and the zone-based algorithm. In short, for a point to be considered in a zone it must fall within the bounds of the zone. (There is a slop factor in some cases, but only a very small one.) In the Adobe-contributed side of the code, point values are not integer-rounded, instead they're kept as (some form of) fixed. Rounding just the BlueValues means that points that need to be considered within a zone will fall outside of it at some points in design space.
The majority of this patch changes the storage and parsing of BlueValues to keep them as FT_Fixed. No significant code changes were needed because the values are converted to Fixed anyway when stored in CF_BlueRec. No attempt was made to address problems in the older pshinter code beyond converting the values from FT_Fixed to FT_Short when copying the private dictionary. (However, as the point values are also rounded in that code, the problem is much less likely to occur, although inconsistency between rounding and truncation could cause an analogous problem.)
I also added some trace code to output blended values, as some problems are difficult to track down without access to final values.
The test suite included with the FreeType repo is quite minimal, making me concerned about what I might have missed. Although existing fonts will be processed differently, that shouldn't matter as long as the fixed value arithmetic and comparisons are consistent (e.g. what was FT_Short data should be in the more significant bits of the FT_Fixed, with the lower bits being 0). Anyway, I assume you have your own testing philosophy and that we can work together to resolve any issues that come up with testing, or that you can direct me towards other tests I need to attend to.