Jit64: dcbx loop detection for improved performance when invalidating large memory regions.

[AdmiralCurtiss]

So unfortunately, I have to report that our recent dcbx fixes have once again made Mario Sunshine's boot sequence and A Boy and his Blob in general slow again.

I profiled this a bit and it turns out the big performance issue comes from a game calling dcbx, failing the BAT check on memory that is not mapped in the BAT, and then JitCache_TranslateAddress() having to go through the rather slow TranslatePageAddress(). This wouldn't be so bad once, but:

• Mario Sunshine calls this on the entire address space, one cache line at a time.
• A Boy and his Blob does this all the time in the background, on multiple ~266KB regions.

This, as it turns out, is slow. Profiler in Mario Sunshine's boot sequence shows >70% CPU usage in just the page translation code. Which makes sense when you think about it, we're effectively invoking InvalidateICache() about 134 million times.

This PR tries to detect such loops and transform them into larger invalidation calls, limited by the remaining downcount, instead of one per cache line.

Probably want an ARM implementation of this too.

[JMC47]

We probably need to do this before the end of the month for the progress report, since it'd be nice to have performance and compatibility.

[Pokechu22]

For reference, libogc's cache_asm.S is (I think) a disassembly of the relevant SDK functions. You can see that almost all of the Range ones follow that pattern. The only exceptions are __LCEnable and LCAllocTags, which have two cache-related instructions per loop instead of one.

[JMC47]

I can confirm there's no more stuttering in Arc Rise Fantasia, Pokemon Colosseum's startup, and Super Mario Sunshine. Mario and Sonic at the London Olympic Games and Happy Feet are not crashing with this optimization.

[JosJuice]

LGTM. I will submit a JitArm64 version as a follow-up PR once this is merged.