DSP masking and sign extension fixes

[Pokechu22]

The cr and prod.h registers are 8 bits and do not experience sign extension. Also, the SR_100 bit always seems to read back as 0, regardless of what's written to it sr. Lastly, ac0.h and ac1.h do experience sign extension; this is already implemented, but the implementation worked incorrectly on the interpreter when the whole acc0 or acc1 register was updated and then ac0.h or ac1.h were read back directly.

Results

Apologies for how unreadable this is. Think of it more as a table of thumbnails than something you can directly compare.

Test	Hardware	Old JIT	Old Int	New JIT	New Int
Less
FFFF
0000
007F
0080
0100

For the less test, the JIT behaves the same as it did before and as it does now, as it handled sign extension properly. Its result is not correct for the sr register, but that's a separate issue (the JIT seems to not update flags for overflow properly) which will be handled later. The interpreter now exactly matches hardware.

For the other tests, the old JIT and old interpreter had the same incorrect behavior, and the new JIT and the new interpreter have the same behavior that matches hardware.

I'm not completely confident on the code for the JIT, which I based based on the code for DSP_REG_ACH0. It seems to work, but the TODO about immediate values is a bit odd.

[shuffle2]

kinda unrelated, but have you seen https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/DSP/Interpreter/DSPIntMultiplier.cpp#L104 / know example that triggers the error the comment is talking about? Wanted to check it out before (but don't have hw to test on... :) )

[Pokechu22]

I don't, but I'm guessing it's similar to the rounding that happens with e.g. clrl (which seems to be round-to-even), probably complicated by the fact that there are two middle product registers (and Dolphin doesn't currently emulate the way the two product registers are written during multiplication; I don't think it's been documented anywhere and I haven't looked into how it works).

[lioncash]

Echoing what @Tilka said on IRC in that we really should be making the tests for the unit-testing system that runs for every PR instead of for one that needs to manually be run