Refactor opcode decoding a bit to kill FifoCommandRunnable.

Separated out from my gpu-determinism branch by request.  It's not a big
commit; I just like to write long commit messages.

The main reason to kill it is hopefully a slight performance improvement
from avoiding the double switch (especially in single core mode);
however, this also improves cycle calculation, as described below.

- FifoCommandRunnable is removed; in its stead, Decode and DecodeSemiNop
return the number of cycles (which only matters for "sync" GPU mode), or
0 if there was not enough data, and are also responsible for unknown
opcode alerts.

To minimize duplication, the actual cycle counts are stored in an enum,
but some still exists.  In the future it would probably be a good idea
to merge Decode and DecodeSemiNop into one function, because they're
very similar.

- FifoCommandRunnable used a fixed, large cycle count for display lists,
regardless of the contents.  Presumably the actual hardware's processing
time is mostly the processing time of whatever commands are in the list,
and with this change InterpretDisplayList can just return the list's
cycle count to be added to the total.  (Since the calculation for this
is part of Decode, it didn't seem easy to split this change up.)

To facilitate this, Decode and DecodeSemiNop also gain an explicit 'end'
parameter in lieu of FifoCommandRunnable's call to GetVideoBufferEndPtr,
which can point to there or to the end of a display list (or elsewhere
in gpu-determinism, but that's another story).  Also, as a small
optimization, InterpretDisplayList now calls OpcodeDecoder_Run rather
than having its own Decode loop, to allow Decode to be inlined (haven't
checked whether this actually happens though).

DecodeSemiNop, which doesn't traverse display lists at all, still uses
the old fake value of 45 cycles.  There's probably some way to improve
this.
A bit out of scope, but what do you think about making this to depend on the amount of vertices?