gba: fix timing of initial DMA wait cycles (ares-emulator#1461)

DMAs on the GBA wait for two cycles before taking control of the bus.
While ares implements this behaviour, ticking these cycles before
running DMAs causes the DMA to run early in ares when the current call
to `CPU::step()` runs for a number of cycles equal to or greater than
the number of DMA wait cycles left.

This PR addresses the issue by ticking DMA wait cycles after running all
DMAs that are currently ready, fixing several timing test cases in the
mGBA test suite, and improving timings in the [Hades DMA start delay
tests](https://github.com/hades-emu/Hades-Tests/blob/master/source/dma-start-delay.c).

ares/gba/cpu/cpu.cpp

@@ -54,17 +54,17 @@ auto CPU::main() -> void {
 auto CPU::step(u32 clocks) -> void {
   if(!clocks) return;
 
-  dma[0].waiting = max(0, dma[0].waiting - (s32)clocks);
-  dma[1].waiting = max(0, dma[1].waiting - (s32)clocks);
-  dma[2].waiting = max(0, dma[2].waiting - (s32)clocks);
-  dma[3].waiting = max(0, dma[3].waiting - (s32)clocks);
-
   if(!context.dmaActive) {
     context.dmaActive = true;
     while(dma[0].run() | dma[1].run() | dma[2].run() | dma[3].run());
     context.dmaActive = false;
   }
 
+  dma[0].waiting = max(0, dma[0].waiting - (s32)clocks);
+  dma[1].waiting = max(0, dma[1].waiting - (s32)clocks);
+  dma[2].waiting = max(0, dma[2].waiting - (s32)clocks);
+  dma[3].waiting = max(0, dma[3].waiting - (s32)clocks);
+
   for(auto _ : range(clocks)) {
     timer[0].run();
     timer[1].run();