Complain about threadsafe events during netplay.
Add a supposedly deterministic dual-core VideoCommon option, bSyncGPUAtIdleOnly.

Basically, the GPU thread continues to start working as soon as the
fifo is populated, but instead of indicating completion (via
ScheduleEvent_Threadsafe and atomic variables) and causing an
interrupt as soon as it's actually done, it sets a flag which the CPU
thread handles at certain points - generally on idle (so idle skipping
is required).  This involves separating CommandProcessor::fifo into a
CPU and GPU version (only when the option is on), and copying the
former to the latter on SyncGPU().

In theory, this should only desync if the CPU inspects an EFB copy or
whatever before getting the interrupt, which should not happen.  There
are probably bugs in this implementation though.

In Melee this does not seem to hurt performance compared to normal
dual core.

Todo:
- see if it actually works
- expose this option (currently stuck on)
- do something if dual core or idle skipping are off
- turn FORCE_WHINE_ABOUT_THREADSAFE off
ProcessFifoEvents shouldn't read interrupt*Waiting in bSyncGPUAtIdleOnly mode.

Those don't correspond to CoreTiming events in that mode anwyay.
Use an explicit variable to wait for the GPU thread...

rather than copying the conditions in the big while loop.  I *think*
this doesn't make a difference unless (a) there's a breakpoint and (b)
the CPU thread gets really unlucky and observes the change to
CPReadPointer but not the immediately following change to
CPReadWriteDistance... but the difficulty of working that out
demonstrates why the change is needed.
Don't set CPReadWriteDistance to 0.

Only matters for breakpoints, which are separately broken.
Add SyncGPUIfIdleOnly to EFB access and perf queries.
Fix stopping emulation.
Make SafeCPReadPointer do what it actually does, and document it.
Get rid of racey gpuBusy in favor of a safer version of the thing I said was terrible.

Either atomics are hard or I'm stupid.  Probably both.

To make it not racey, get rid of CPReadWriteDistance and just use
CPReadPointer and CPWritePointer.
Refactor SetCpStatus, hopefully fixing breakpoints.

Now it's only called in a single place in each mode.  Normally this is
the GPU thread, because everything needs to be checked when
CPReadPointer changes, and watermarks shouldn't need strict timing so
there's no need to also call it from some other thread.  In
bSyncGPUAtIdleOnly mode, we ignore watermarks, so it's called on the
CPU thread after cpuFifo.CPReadPointer is updated, to check for
breakpoints.
Give deterministic dual-core a proper option (but don't expose it in the GUI).

The default value is 2, which means only do it during netplay or movie
record.  Setting it to 0 or 1 forces it off or on (though it will
still currently be off if dual core or idle skipping is off).

This requires being able to turn it on and off turing emulation, since
a movie could be started at any time.
Fix SafeCPReadPointer bugs.
Rename SyncGPUAtIdleOnly -> DeterministicGPUSync.

The idea was that it got feedback from the GPU thread only during Idle
and on special occasions rather than constantly, but the special
occasions belied the name, and it was too similar to SyncGPU, which
does something entirely orthogonal (and is not yet compatible).  This
name is more descriptive.
Fix freeze on close.
Remove unused variables and functions.
Simplify and hopefully correct handling of SET_TOKEN and SET_FINISH.
Fix the breakpoint fix.

SetCpStatus needs to be called when bFF_BPEnable changes, not just
when the read pointer changes.  This fixes Super Mario Sunshine.
Turn off FORCE_WHINE_ABOUT_THREADSAFE.
Fix Sunshine in deterministic mode.

When BPMEM_PE_TOKEN_ID is written right after BPMEM_PE_TOKEN_INT_ID in
deterministic mode, don't entirely overwrite interruptTokenData and
forget about the interrupt.  Duh.
Clean up GatherPipeBursted.  Shouldn't actually affect anything.