Fix a bug with update loads in memcheck mode.

In two cases, my old code was using a temporary register but not saving
it properly; it basically worked by accident (an otherwise useless
FlushLock was causing CallerSavedRegistersInUse to think it was in use
by the GPR cache, even though it was actually a temporary).

I'm going to modify this in the next commit to use RDX, but I didn't
want to leave a broken revision in the middle.
Rationalize temporary register usage.

Rather than using a variety of registers including RSI, ABI_PARAM1
(either RCX or RDI), RCX, and RDX, the rule is:

- RDI and RSI are never used.  This allows them to be allocated on Unix,
bringing parity with Windows.

- RDX is a permanent temporary register along with RAX (and is thus not
FlushLocked).  It's used frequently enough that allocating it would
probably be a bad idea, as it would constantly get flushed.

- RCX is allocatable, but is flushed in two situations:
    - Non-immediate shifts (rlwnm), because x86 requires RCX to be used.
    - Paired single loads and stores, because they require three
    temporary registers: the helper functions take two integer
    arguments, and another register is used as an index to get the
    function address.
These should be relatively rare.

While we're at it, in stores, use the registers directly where possible
rather than always using temporaries (by making SafeWriteRegToReg
clobber less).  The address doesn't need to be clobbered in the usual
case, and on CPUs with MOVBE, neither does the value.

Oh, and get rid of a useless MEMCHECK.

This commit does not actually add new registers to the allocation order;
it is intended to test for any performance or correctness issues
separately.
Actually add RCX, plus RDI and RSI on Unix.

I have no idea if this improves performance because I'm sick of running
the benchmark. :P