Reimplement RSX reservation access

[kd-11]

This PR adds block-level reservation management for RSX vs CELL. The basic design philosophy here is that when "Accurate RSX reservations" is enabled, access to memory shared between CELL and RSX is accessed in an exclusive manner. Multiple CELL threads are free to simultaneously manipulate memory as they have their own synchronization mechanisms, but RSX accesses said memory in an exclusive manner. This fixes a lot of problems where SPU/PPU has a reservation line but data is clobbered by RSX DMA operations. TSX normally fixes this issue for capable CPUs which is why some users can play affected games at good performance with no issues.
The advantage of doing it this way of course is performance, the performance hit is now much less and games that require the option to work see comparable performance to using TSX, being only slightly behind.
While this change is now heavily simplified and reuses existing sync primitives, it was previously overly complicated with custom page-locking mechanism but that solution was scrapped as it was overdesigned and broke very easily. The new version also has slightly better performance (about 1 fps or so).

To Testers: Please focus on games that require the "Accurate RSX reservations" option. If you have TSX, compare TSX on vs TSX off + the option enabled.

[elad335]

I think you need to add it to texture faults handling as well.

[kd-11]

Those are atomic as the pages are no-access. Flushing is done in mirror space so no way we can have contesting writes.

[elad335]

Is there a opential deadlock here where SPU enters texture cache fault handler for adderess X on a reservation then when RSX waits on the same address to be unlocked it cannot handle the texture cache fault and the SPU and RSX freezes because they wait for each other forever?

[xddxd]

On this PR L.A Noire locks up in the menu with reservations enabled.
Master: RPCS3.log.gz
PR: rsrv.log.gz

[kd-11]

FTR, deadlock on RSX-is-asleep-while-SPU-thread-is-in-exception-handling was always a problem. Fixing it in a straightforward manner would be terrible and allows other threads to essentially starve RSX of the locks, which means a custom primitive with first come first serve is needed that optionally invokes a callback while waiting and still maintains request order. This is easy to do on *nix but not so much on windows so I need to think of something that plays a bit nicer and doesn't scare people. I have a few ideas I'd love to try out; we'll see which implementation is the winner.

[kd-11]

@xddxd I forgot to request a retest, I fixed a potential deadlock.

[xddxd]

Same behavior.

[kd-11]

L.A Noire discussion moved to #9134
Unfortunately that title is so unstable that debugging becomes hit or miss. Sometimes it seems to be working then it is not, then you change something insignificant and it seems to work again only to break after a few minutes - it's not a reasonable target for this kind of investigation.