Fixes LIT (https://bugs.dolphin-emu.org/issues/13635). The text does not include normals, but has lighting enabled. With the previous default of (0, 0, 0), lighting was always black (as dot(X, (0, 0, 0)) is always 0). It seems like the normal from the map in the background (0, 0, 1) is re-used.
LIT also has the vertex color enabled while vertex color is not specified, the same as SMS's debug cubes; the default MissingColorValue GameINI value of solid white seems to work correctly in this case.
No need to materialize the immediate if it is zero, we can just use WZR.
Before:
mov w27, #0x0 ; =0
str w27, [x29, #0x1178]
After:
str wzr, [x29, #0x1178]
In VolumeVerifier.cpp, constructing a `std::string_view` of the volume's GameID is unnecessary, as `std::`(`ranges::`)`binary_search` supports heterogeneous lookup. The usage in GameFile.cpp is a perfect example.
In OGLConfig.cpp, `std::views::reverse` is used rather than sorting using `std::ranges::greater` in order to parallel other instances of reverse iteration in the function.
In DSPCore.cpp, there were two `std::fill` uses that could be simplified using `std::fill_n`. Due to their proximity with other `std::fill` algorithms being modernized with ranges, I chose to make these examples into the rare `std::ranges::fill_n`.
In StringUtil.h, the lambdas wrapping `Common::ToLower(char)` and `Common::ToUpper(char)` were only necessary due to the function names being overloaded.
Many games call GXSetGPFifo() without first waiting for the GP to finish
consuming outstanding commands in the previous GP fifo. Normally,
Dolphin runs OpcodeDecoding in 1000-cycle time slices. In that time
frame, GXSetGPFifo() has probably completed and the GP read pointer now
points to entirely new memory. If the last GP fifo copy ended in an
incomplete command, the new GP fifo would most likely desync for a
while. To avoid all this, give the GP a time slice right now to copy the
remaining data from the previous GP fifo.
