Implement Support for Custom Fonts

[CryZe]

This implements the support for specifying custom fonts in layouts. Unlike the original LiveSplit, this acts more as an override here. One reason for this is to make it easier for platforms to just not have any font support in the first place, such as terminal applications where it's simply not possible to change fonts. If a user never specifies a custom font, it's expected that the application can then use any font that is appropriate for the situation.

Fonts are specified as a font family name and additional styling information, such as the style (italic / regular), weight and stretch of the specific font to select out of the font family. The application then chooses the most appropriate font that it can find, falling back to its default fonts if it can't find the font. It turns out that different APIs and applications have very different notions of what a family name even is. This is because a font can have lots of different, even conflicting, names in its name table. The kinds of names that you specify there have evolved over the years, so there's old entries and newer entries, where the font selector has to make very unclear decisions which to prefer. It seems like modern APIs prefer to select for the Typographic Family Name (Name ID 16), with a fallback to Font Family Name (Name ID 1) in case the former is not available. Old APIs such as GDI do their own special thing though, complicating the matter even more. I have yet to fully grasp what GDI even does. Even among browsers the font selection seems to work differently. So it all seems like a big mess where you can only try to align with as many APIs as closely as possible, and a correct solution is simply not possible. Since the original LiveSplit seems to select its fonts through GDI, we also run into the issue of importing these identifiers properly. Technically we could query GDI for the specific font, but this is only possible on Windows and is not that easy, as we'd need to parse out the typographic family name, but GDI doesn't have an API for that, nor does it give you the path of the font or access to the font's data. It gives you access to the raw data of individual tables you query for, but ttf-parser doesn't expose a way to parse individual tables in its public
API. So for all of these reason, for now we only implement a fallback converter for these identifiers where we attempt to pop individual style tokens off the end of the identifier to turn it into styling information and the family name. This is however also flawed in other ways, such as those GDI font identifiers also being limited to 32 characters, meaning that you can end up unlucky and have a style token be cut off in the middle at the end, at which point we can't recognize it as such anymore.

Another issue was vertically aligning text. Fonts have various vertical lines, such as the ascender (being the very top a glyph can reach), the baseline (the line that glyphs are written on top of), and the descender (the very bottom a glyph can reach). These three lines can be arbitrarily defined by a font. It is impossible to take two fonts and apply a linear transformation to it to align all three of these lines. Considering we usually have the text font and the times font in the same line, we however still need to make them look aligned. Also there is the possibility that more fonts get involved as certain glyphs may not be available in these fonts, such as emojis. At this point you definitely want to align their baselines. If you also keep a fixed scaling across the fonts, which is usually what you also want, you end up with ascenders and descenders that are all over the place. However this is basically a necessity, there's nothing you can do about this without harming the previously mentioned important properties. Therefore it can be concluded that any sort of attempt at vertical centering is basically impossible and you instead need to choose a baseline that looks decent across many different fonts. Coincidentally this is already what the renderer did, so nothing needed to be changed in this regard. Though we may want to take a closer look at possibly better positioning for that baseline.

The rendering unit tests aren't allowed to use any custom fonts, as that otherwise causes those tests to fail on different platforms where these fonts may not be available. Also this introduces a new font-loading feature where our renderer only loads any fonts if the feature is active. This is because the renderer could be compiled for a platform where the code isn't able to load any fonts for, such as in my experiments to compile the renderer to the GameCube and Gameboy Advance. So this is another reason why we simply can't load any custom fonts in our tests.

Resolves #104

[CryZe]

Oh god, font-kit really doesn't like to be cross compiled... ooof