Add iQue Player support

[Jhynjhiruu]

This PR adds preliminary support for emulating the iQue Player, the revised version of the Nintendo 64 released in Mainland China in late 2003. It modifies the N64 core to add support for the console's unique hardware.

The iQue Player doesn't launch games from cartridges; instead, it has a slot on the back for a card to be inserted, which contains a NAND chip. On the NAND is the console's kernel, system menu and all software.
Games on the card are encrypted and signed, and must be launched from the system menu. Metadata about the games is stored in a file on the card. As such, it doesn't really make sense to support the common emulator feature of dragging and dropping a game onto the window to launch it.

When launching the core for the first time, it will prompt for the necessary files dumped from a console: a dump of the NAND with corresponding spare data, and the keystore. It isn't really feasible for the emulator to auto-generate these, since the keystore contains various global and console-unique key data; external tools can do this.

Equally, it doesn't make much sense to provide a virtual filesystem for the card contents; instead of having a global operating system with filesystem capabilities that games can use, the iQue Player variant of Libultra interacts with the NAND directly, so HLEing the filesystem is mostly infeasible.

The iQue Player has a soft power button, which has been partially implemented. Pressing it while in a game resets the console to the system menu, and pressing it again from the system menu powers off the console. Currently, powering off the console does nothing; it's unclear how to handle this.
Additionally, I've temporarily added a button mapping to the first controller port for the power button, but this solution isn't very good and I've had to add some awful code to handle it. An ideal solution would be to have an option in the GUI for the power button, but that then doesn't allow mapping it to a controller for convenience.

There are still some things that haven't been implemented:

• DRAM: the iQue Player replaces the N64's slow RDRAM with much faster DRAM, and the RCP interface was slightly adjusted. This hasn't been reverse engineered, since we don't yet have a great way to get output from a console before the DRAM is initialised, but leaving the existing N64 RDRAM emulation in place works fine for now.
• Multi-NAND cards: the iQue Player theoretically supports having up to three NAND chips attached to the console at once, though no existing hardware or software has been found that would take advantage of this.
• Various RCP registers: quite a lot of writes to registers don't have any known effect at the moment, which currently get printed out as [unimplemented]. As more reverse engineering gets done, the number of unknown registers will hopefully decrease.
• Various traps: we know from debugging strings that there is hardware support for trapping various errors and behaviours and directing them to one of a couple of vectors, but we don't have any examples of code that uses or triggers them, so they haven't been reverse engineered yet - this will mostly only be of interest to homebrew developers, since obviously no official games trigger hardware error conditions.
• PIF weirdness: the iQue Player has no PIF, and instead parses Joybus commands with a custom state machine. We've done a lot of hardware tests and mostly determined how it works, but there are still some edge cases that haven't been tested so we're not entirely sure that it's correct.
• Various bits and pieces of hardware behaviour: for several bits of the hardware (most notably the RTC), we've implemented support for documented behaviours (e.g. ticking the RTC normally with valid data), but where the documentation doesn't specify what should happen we haven't yet written the necessary hardware tests.
• VI: the video circuitry on the iQue Player is a little different, and so pixel_advance needs to be set differently to avoid corrupted display - we haven't attempted to emulate this. If we're lucky, might this fall out of accurate general VI emulation when considering the video clock? cc @rasky

Serialisation is currently broken. This is because we didn't always keep track of which changes required adjusting the serialisation, so not everything we've added gets serialised properly. This should be fairly simple to fix, if someone looks over the changes and compares them to what's being serialised.

We also need to remember to update the serialisation version before merging.