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`.

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...)

Previously, we had WBFS and CISO which both returned an upper bound
of the size, and other formats which returned an accurate size. But
now we also have NFS, which returns a lower bound of the size. To
allow VolumeVerifier to make better informed decisions for NFS, let's
use an enum instead of a bool for the type of data size a blob has.

DTLX01 can be either a Freeloader or Action Replay, so it's
inappropriate to always use the same title and cover for it.