Rework the entire logic of the GDB stub

[aldelaro5]

The GDB stub is an old and very unmaintained feature that can be very useful when paired with reversing tools like ghidra, but being unmaintained, it didn't worked very well (and only worked on the interpreter).

This PR does the ground work to rework it entirely to at least a usable state. Here's a summary of the changes:

• The stub process commands logic now runs every so often while the emulation is running to process potential ctrl+c commands
• The main gdb stalling logic is now in the CPU::Run instead of the interpreter whenever gdb still has control (basically, after a ctrl+c or breakpoint, but not user pause). This effectively means all CPU backend are now supported.
• If active, boot to pause is effectively forced until we get a connection and a continue command (this behavior may be changed in another PR, but the focus of this one is to just make it work).
• Completely rework the breakpoint processing logic to use the same functions than the integrated debugger instead of tracking them separately since the integrated debugger already works very well
• Add support for the T command that checks if a thread is alive (this is something ghidra wanted for mgba and it's trivial to support so might as well)
• Allow the stop button to kill the gdb connexion with it
• Remove the cmake option and the ifdefs, the code is now always enabled
• Rework the logs (upgraded some debug to info and added one when we break due to GDB)
• HUGE refactor of the code as it was far from respecting the current coding style

To note: the hardest part was figuring out how to coordinate this with the core safely: I am not experienced with multithreading stuff so when reviewing, I recommend to pay close attention to how this interacts with the core and to make sure there's no race or anything unsafe I am doing here. This pr is mostly to make sure the approach done here is correct for potential further improvements.

For now, I can vouch for a gdb shell to work (mostly tested on the one provided by devkitppc, but gdb-multiarch seemed to work well), but ghidra seems to have issues of its own that doesn't seem to be in the scope of Dolphin.

[Warepire]

• If active, boot to pause is effectively forced until we get a connection and a continue command (this behavior may be changed in another PR, but the focus of this one is to just make it work).

This is how gdbserver feature of gdb work when used for remote debugging, if this functionality is not in the way it might be a good idea to keep, as it will work like most gdb users expect out of the box.

[aldelaro5]

• If active, boot to pause is effectively forced until we get a connection and a continue command (this behavior may be changed in another PR, but the focus of this one is to just make it work).

This is how gdbserver feature of gdb work when used for remote debugging, if this functionality is not in the way it might be a good idea to keep, as it will work like most gdb users expect out of the box.

The idea that me and @phire were talking about were you would start the emu normally WITHOUT the stub, but have the port in the settings and you would use some sort of menu option to start it so it would effectively stall AFTER the emulation started. This is actually how mgba works: you can start and stop it on demand.

It's fine for now if it only works on boot, but I was just saying we might improve it in another pr to not force it on boot.

[aldelaro5]

Ok I addressed the review, fixed compilation and also added a race condition fix I found while testing on windows.

[phire]

I'm not seeing any flaws in the multi-threading logic.

But there are a few minor fixes.

[dreamsyntax]

Does this PR make #6325 obsolete?

[phire]

Does this PR make #6325 obsolete?

Looks like it mostly obsoletes it, and does so with much less code and without an entire thread.

[phire]

A few of your commit messages need cleaning up (Code Review Code Review)

other than that and the missing comment in CPU.h, I think it's ready.