Moves everything to fmt-style {0} format specifiers instead of
printf-style %s etc.

This has a BIG effect on translations, so do a complete rework of that
at the same time.

The end goal is that all code translated strings (with tr()) will use
numbered fmt format specifiers - e.g "string {0} precedes {1}" so they
can be re-ordered by translations as necessary.

While doing this, rewrite a number of areas that construct strings from
fragments - translations would *much* prefer to be able to
translate/reorder the block as a whole.

All this made the old POT template pretty useless, also not helped by
the fact that seemed to have been "seeded" by dumping the string table
of the original executable - so actually contained a large number of
strings we never used.

Note that forms and "game data" (like names for things) are excluded
from the gettext-based code translation. The goal is to allow form XML
and gamestate to be modified on a per-mod per-language basis. Though
arguably much of the Gamestate is proper nouns - which may not really
require translation.

The idea is that mods can add gamestate patches and append data search directories.

The idea is that the *vast* majority of the Gamestate doesn't need translation - proper nouns etc. and the game setting is in an English-speaking country. But I'm allowing that just in case there are things in there that probably should be translated.

And the data override allows 2 major things - forms and image replacement. The idea is that a language that changes strings on a Form replaces the corresponding Form XML. This allows rearrangement, reflowing and resizing as necessary. Same with images - as many UI images contain text.

This does have a limitation of that only the "latest" in the data stack for each file is read - if two mods modify the same form, for example, only the last in the load order will be visible to the game.

Note: we use language codes as returned by boost - that "language_COUNTRY" format - e.g. "en_GB"/"en_US". The idea is that if the country isn't available, it falls back to the parent language - e.g. "en_GB" would fall back to an "en" folder and patch file, if such a things exists.

Mostly enum casts for debug output and transitive header changes

These seem to differ between the clang-format 18.1.8 I have locally

And seem to be somewhat weird an inconsistent - different spaces for
different constructors?

eh, whatever.