Improvements to sceMpeg: fix end cutoff, early audio end, and minor

Unfortunately it's a bunch of changes, but most are needed for the games I tested to all be happy.

First, there are a few that aren't really necessary, but match my tests / fix crashes in it:
 * sceKernelGetThreadmanIdType() crash fix (was using this to decipher the sceMpeg structs in my tests.)
 * sceMpeg() double init error (this clearly happens on hardware, but didn't see any games that cared.)
 * Correct scePsmfQueryStreamOffset() return value (@raven02 confirmed 1 was no longered needed in #2128.)
 * Makes sceMpegCreate() delay a bit, might improve timing, definitely happens on firmware.

Aside from that, this:
 * Tries to calculate the packets on the ringbuffer much more accurately, since Wipeout *does not* like it when all the packets are consumed right away.
 * Makes minor adjustments to how mpeg put works (it's still not correct but it should avoid overflow now like the firmware actually does, see comment on how it's off but it's a pain to fix and probably not important.)
 * Decodes re-ordered I/P frames.  These get moved to the end based on how MPEGs are decoded, so if you don't keep calling decode, you never get them.  FFmpeg's example shows that you should keep calling it with a NULL packet (but almost no other examples actually do, go figure..?)
 * Detects end of video more accurately to go along with that.
 * Detects end of audio more accurately because the above made the Crisis Core video never end (since the audio ends earlier.)  Also confirmed with the Senjou no Valkyria 3 SEGA video, which ends audio early via a test.

I pulled out this commit, but my tests show this happening: c656df2d6eb89217476675bf4ed6e09a800b24eb
I can't hear audio in virtually any video so no idea if it's correct.

@oioitff, if you want to take a look at these changes and tell me if anything looks wrong I'd appreciate it.

-[Unknown]