GDB and LLDB will send a ctrl-c character (\x03) to the stub
to interrupt it after a continue where it doesn't stop on its own.
E.g.
```
void foo() {
foo2(); // Continue from here.
while (1) {} // Loops here until ctrl-c in the debugger.
}
```
mGBA had code to handle the ctrl-c but because in _continue
we set the paused status after calling mDebuggerModuleSetNeedsCallback,
the callback was never set so nothing was looking for new messages
while we were running. We should instead set the paused state then call
mDebuggerModuleSetNeedsCallback.
mDebuggerModuleSetNeedsCallback calls mDebuggerUpdatePaused, and all
other calls to mDebuggerUpdatePaused update the paused state before
that call so this matches existing usage of that too.
With this fix, after the continue _gdbStubPoll is called periodically
and will pick up the ctrl-c as it comes in (_gdbStubWait is used when
we are stopped in the debugger).
This fixes ctrl-c to interrupt when using lldb and gdb.
The 'g' packet is handled by _readGPRs which has a special case for
the PC due to the way the CPU reports the PC value.
This was added by added by a967f9aac4.
The 'p' packet is handled by _readRegister which did not have this
special case for PC. This lead to GDB reporting the correct PC value
but LLDB not, as the latter used 'p' instead.
This meant you saw things like this:
0x80002a4 <+16>: str r0, [sp, #0x4]
0x80002a8 <+20>: bl 0x80001f0 <----------expected to be here.
-> 0x80002ac <+24>: b 0x80002b0
Where you expected to be about to bl to another function,
but it looked like you had already done it.
And more obviously, when you first attached to the GDB stub,
the PC was reported as 4 not 0.
