The data structure of the `bi2.bin` file in which the simulated memory
size is set:

> **13.2  Disk header Information**
>
> this is loaded to the Address in `0x800000f4` when a disc is initialized by the IPL
>
> |  offset  | end | size | Description           |
> | :------: | --- | :--: | --------------------- |
> | `0x0000` |     |   4  | Debug-monitor Size    |
> | `0x0004` |     |   4  | Simulated Memory Size |
> | `0x0008` |     |   4  | Argument offset       |
> | `0x000c` |     |   4  | Debug flag            |
> | `0x0010` |     |   4  | Track Location        |
> | `0x0014` |     |   4  | Track size            |
> | `0x0018` |     |   4  | Countrycode           |
> | `0x001c` |     |   4  | ?                     |

See https://hitmen.c02.at/files/yagcd/yagcd/chap13.html#sec13.2.

Most GameCube games set the value to `24 MiB`, which matches the
physical memory size. Most Wii games set the value to `0 MiB` (unset).
The debug build of _Mario Kart: Double Dash!!_ is one game that sets the
value to `48 MiB`.

In some Triforce games (e.g. _F-Zero AX_), the bytes that follow the
region flag in the `boot.id` file (at `0x38`) happen to be `0x00`.
However, in other games (e.g _Mario Kart Arcade GP 2_), it seems the
region flag is padded with `0xFF`.

_Mario Kart Arcade GP 2_ (`boot.id` in the USA version):
```
00000 0000:  42 54 49 44 00 00 01 E0  00 00 00 01 00 00 00 01  BTID.... ........
00000 0010:  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ........ ........
00000 0020:  47 43 41 4D 00 00 01 C0  07 D3 05 0F 00 00 00 07  GCAM.... ........
00000 0030:  53 42 4E 4C 00 00 00 00  0E FF FF FF FF FF FF FF  SBNL.... ........
                                      -----------
                                           ^
                                           |
                                      region flag
```

When the region flag was tested in `switch` statements (where a single
byte was expected in the `case`s), the test would fail, depending
on the game.

This issue would lead to the wrong calculation of the country in
`VolumeDisc::GetCountry()`, which was then used to build the game ID in
`VolumeDisc::GetGameID()`.

The solution is to test using only the least meaningful byte in the
region flag.

Unexpected game IDs were first noticed with USA version of _Mario Kart
Arcade GP 2_, which was wrongly assigned the same game ID that is given
to the Japan version (i.e. `GNLJ82`). The correct game ID for the USA
version is `GNLE82`.

We often use game IDs in paths, so we should try to make sure path
traversal is impossible in game IDs. Admittedly, doing any kind of real
attack using the six bytes available in game IDs is unrealistic, but no
game ID should contain non-alphanumeric or non-ASCII characters anyway.

Might also fix https://bugs.dolphin-emu.org/issues/13982 by skipping
converting between encodings for game IDs.

VolumeDisc: Fix Triforce's GetGameID memcpy by checking MakerID's size

Fixed a bug caused by static usage of Core::System::GetInstance()
Removed unused headers
Removed unneeded code
Optimised code
Added sanity checks
Added SafeCopyFromEmu/SafeCopyToEmu
Set Triforce buttons to be translatable

Yellow squiggly lines begone!
Done automatically on .cpp files through `run-clang-tidy`, with manual corrections to the mistakes.
If an import is directly used, but is technically unnecessary since it's recursively imported by something else, it is *not* removed.
The tool doesn't touch .h files, so I did some of them by hand while fixing errors due to old recursive imports.
Not everything is removed, but the cleanup should be substantial enough.
Because this done on Linux, code that isn't used on it is mostly untouched.
(Hopefully no open PR is depending on these imports...)

SPDX standardizes how source code conveys its copyright and licensing
information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX
tags are adopted in many large projects, including things like the Linux
kernel.