Theming

[19wintersp]

Fixes #536, #570

Supersedes #621

There's a lot of repetition in the rendering code at the moment unfortunately, which is mostly down to the way the existing code was written; I've tried to avoid changing too much so that has been retained. In the future this code will be rewritten when implementing the design changes. Potentially the Gdiplus::Graphics wrapper could be modified to accept PaletteKeys as well as raw GDI+ objects, which would also clean things up somewhat.

Still to do, in rough order:

• Fix tests – I haven't touched these at all, so they're totally broken; wouldn't be opposed to just pointing an LLM at them since a lot of them are really redundant
• Add new tests to cover new code
• Fix "StandardButtons" – the "constructors" taking Gdiplus::Colors should be changed to take PaletteKeys instead, since they aren't used; the code here is really awful anyway, and should probably be rewritten
• Check colour palettes for contrast, since some of the timer colours aren't very readable currently
• Clang format

When merging, please squash merge!

[sonarqubecloud]

Quality Gate failed

Failed conditions
8 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[19wintersp]

More or less finished now; I've tried to remove all of the abortive changes from previous attempts at this feature, but there may still be a few lingering files changed. The code has been formatted with clang-format-18; I don't know why the Action seems to be using a different version (20?) to that specified in the Dockerfile. Sonar's recommended changes are irrelevant: the changes to "resource.h" and "TestEnvironment.cpp" are not possible due to external API constraints (Windows and gMock, respectively); the commented-out code will be removed when that functionality is re-introduced with a rewrite of the UI; to_underlying cannot be used because we use C++20, not C++23; and the declarations in "Palette.cpp" are deliberately formatted as such.

The "TestEnvironment.cpp" files are unfortunate, but I think the duplication is necessary due to the unique shutdown code required for the plugin tests alone; I'd appreciate a better way of doing it if one exists. I'm open to suggestions as to a better name/location for these files, but since they effectively act as an entrypoint to the testing binaries, I think having them in the root is justifiable.

Two regressions are visible to the user: the titlebar of the departure coordination list does not flash, as a temporary measure until this functionality is refactored into the common titlebar code; and the "OP" button is now a different colour by default, depending on the theme.

[kristiankunc]

I've built this locally and am satisfied. Not much to say about the code, other than that there's lots of it unfortunately but all looks satisfactory at first glance