Support Multiple Languages

[Nopey]

New Configuration option "LANGUAGE" lets player choose their language.

• OMF ENGLISH.DAT and GERMAN.DAT are supported.
• Additional languages will be picked up, so long as they have a .LNG file extension; an example Danish Machine translation is added to demonstrate how to do this.
• text_render now renders characters 0x80..=0xFF, such as Ä, ß, and ü.
• OpenOMF-specific language strings are supported via a second language file, such as ENGLISH.DAT2 or DANISH.LNG2
• languagetool has been expanded to support encoding files (Add support for encoding language files #693 has been rolled up into this PR)
• When building openomf, languagetool will be used to build the .DAT2 and DANISH language files. (See BuildLanguages.cmake)
• Languages are built and shipped in CI artifacts.
• Languagetool converts between UTF-8 and DOS CP 437. Currently, all OMF language binaries are CP 437, and all plaintexts are UTF-8. Eventually, we might ship language binaries containing UTF-8.

Older, 990-string-long localization files (like german.dat) are supported by inserting empty dummy entries where OMFv2.1 (the netplay update) added new strings.

Issues that remain:

• Original game font is still being used, so we are limited to code page 437.
• Many hard-coded strings are not being localized, including most of our menus.
• How are tournaments going to be localized? The tournament file format supports a max of 10 locales, and tournaments are discovered at runtime.
• Supporting comments in the language source .TXTs would probably be useful
• Instructions for translators are not written

Obsoletes PR #508 and includes PR #693

[Vagabond]

I've been trying to use this to actually switch over to more of the english.dat strings and there's several issues with using them more extensively:

• Random menu strings end in a lowercase a
• Several strings don't have a direct translation, but instead use formatting (eg. "BEST %i of %ia", or "%s SPEED")
• Several strings are stored vertically, eg string 474 and 475, but we have a vertical rendering mode

Given we also have missing strings already, and some of these strings seem kind of redundant and tied to quirks of the original engine, we may wish to create entirely new translation files, derived from the originals?