This PR doesn't add any new debugging features, but introduces the API that can be utilized for PPSSPP customization.
That interface allows easily overriding the standard behaviors of the assembly instructions. That's what I decided to call "hooking".

I have seen a few PPSSPP mods (and made one too), and I have realized it's fairly hard to implement some advanced debugging/logging in the emulator without harming the performance of the execution. See, modding the JIT requires godlike skills, and the IR interpreter is not fit for that. We're left with the Interpreter, which calls Interpret(instr, op); for all instructions that it sees. It's a wrapper around instr->interpret(op); and the instr is acquired through const MIPSInstruction *MIPSGetInstruction(MIPSOpcode op). The system is slightly complex: there are 28 big tables with predefined MIPS instructions and their handlers. I have removed the constness from these tables to allow the replacing of the standard interpreter functions. It would be way easier than making new CPU cores and copy-pasting all the old code just to make small changes.

namespace MIPSHooks {
	// Fills the MIPSNameLookupTable
	void Init();
	// Disables the hooks
	void Reset();
	// Tries to register a hook
	void Hook(const char* name, MIPSInterpretFunc func);
}

The example usage can be found in my other branch that I've created from this one.

void VtableCracker::Enable() {
	MIPSHooks::Hook("jr", &HandleJr);
	MIPSHooks::Hook("jalr", &HandleJalr);
}

As simple as that.

The tool is for accumulating the destinations of jr t9 and jalr t9 calls.

The name lookup table is initialized when any game is loaded so I thought it'd be a nice demo of what happens when it can't find the names.

One last note: this API needs to be used correctly. I can't enforce it, of course, but if there are multiple possible hook setups, it's necessary to call MIPSHooks::Reset(); before setting up the new ones or else the emu will forget the original handlers.