n64: improve and extend cache coherency checks

[rasky]

To make sure to intercept all possible errors, the check are now performed by the RDRAM module, whenever a RDRAM read/write behind a cacheline happens.

CPU writes to cache is now tracking dirtyness at the byte level rather than whole cacheline level, so that hardware accessing memory does not trigger a false positive for false-shared variables. An initial round of testing has shown that the check would trigger far too much otherwise. Error reporting is also much improved to provide more context to analyze the issue, including tracking the PC at which the hardware DMA was triggered.

For RSP DMA, we do even more: instead of reporting an issue when an area of a cached memory is DMA’d into RSP DMEM/IMEM, we actually just mark those memory locations as tainted, and emit the warning only if RSP later reads them. This is necessary because it is extremely common for RSP ucode to read data beyond the actual buffers it cares about, even though that data is then never accessed.

Some of the warnings issued by Ares have been analyzed on Super Mario 64 and Zelda OOT and in both cases they have been confirmed to be real bugs in cache management made by the game.

For instance, in Mario 64, the programmers forgot to invalidate the cache before loading data for the initial Mario head animation, as reported by Ares now:

[unusual] PI DMA writing to RDRAM address 0x390650 which is cached (missing cache invalidation?)
	Cacheline was loaded at CPU PC: 0xffffffff80183b38
	PI DMA started at CPU PC: 0xffffffff80328558

The game just happens to work because after loading, the game does something else and manages to get the cache invalidated by touching other locations, but otherwise it would be a real bug.

As another example, in Zelda OOT, we get these warnings at boot:

[unusual] AI reading from RDRAM address 190820 which is modified in the cache (missing cache writeback?)
    Cacheline was loaded at CPU PC: ffffffff800b54fc
    Cacheline was last written at CPU PC: ffffffff800b5528
    
[unusual] RSP reading from DMEM address fe0 which contains a value which is not cache coherent
    Current RSP PC: d10
    The value read was previously written by RSP DMA from RDRAM address 00199e40
    RSP DMA started at RSP PC: abc
    The relative CPU cacheline was dirty (missing cache writeback?)
    Cacheline was loaded at CPU PC: ffffffff800b5244
    Cacheline was last written at CPU PC: ffffffff800b5264

These warnings appear to be real bugs in the audio library. Quoting Thar0:

* AudioHeap_ClearCurrentAiBuffer/AudioHeap_ResetStep wipe the AI buffers with CPU writes and 
  then don't write back the cache, and I guess an AI DMA is either in progress or starts before it can
  be properly flushed. On boot this shouldn't matter as gAudioHeap is BSS and is already zero, but
  if the driver is reset later it might cause some minor issues?
* The RSP cache coherency problems is from loading filters in AudioHeap_LoadLowPassFilter.
  The heap allocator returns a pointer to which the CPU writes the filter data.. but the allocator
  writes back the cache before the CPU writes the data 😂

Moreover, this PR also implements all the known SysAD-related CPU freezes that cause the console to crash. We now pass the n64-systemcrash testsuite in full.