Add a command to forcefully shutdown retroarch (CTRL+C) in any non-deadlock situation

Description

Sometimes retroarch crashes in KMS. Sometimes those crashes manifest as a 'freeze' where the video renderer thread crashed but retroarch main thread is still running and thus the TTY doesn't appear. In those situations it's necessary for a command for forcefully quitting (typically CTRL+C) because otherwise the only way to exit this state is hard-reset/shutdown the computer.

In KMS there is nothing listening for the 'hardware' shutdown button (if it exists) and 'gracefully handling it', at least in ubuntu, so the only way is to quit and quit hard, risking file/device corruption. If you don't have a hardware button not even that, and your only option is to remove the plug. This happened to me several times.

More information:
Kernel keyboard shortcuts: https://wiki.archlinux.org/index.php/Keyboard_shortcuts#Kernel_(SysRq)

These commands are supposed to be able to be available in any situation because the input is handled before being passed to any programs. I've had trouble using them when i really really needed them before though. I suspect it's because of the usb keyboard and udev driver interaction, not that it matters here.

Console (TTY) keyboard shortcuts: https://wiki.archlinux.org/index.php/Linux_console#Keyboard_shortcuts

These commands appear to be passed to, and 'eaten' by the retroarch menu running on KMS. It appears there is no actual way to switch TTY, or reboot, or even forcefully shutting down RA with them. I've decided against asking for these to work - except ctrl c - in RA because I suspect at least TTY switch would cause driver permission problems in KMS, even if CTRL+SHIFT+BACKSPACE might work.

I'm not sure if this is influenced by having unmapped 'esc' which is the default quit retroarch button - it's a terrible one - and retroarch doesn't recognize key modifiers in mappings anyway, which would be my alternative. CTRL+C should always work anyway.

Expected behavior

At least CTRL+C could cancel a 'softlock' that doesn't crash completely to the TTY instead of being forced to hardware shutdown. TTY switch and forceful reboot don't need to be operational - especially the tty switch might cause problems with the graphics driver permissions causing a kill of the RA program anyway, but ctrl+c needs to be.

Actual behavior

No way to get out of a unfortunate freeze except hard reset. This freeze happens often when switching cores without shutting them down in KMS, possibly as a result of trying to initialize then switch between glcore/opengl/gles. I'm unsure this happens before or after the new core start.

Steps to reproduce the bug

(It's random, and I suspect it kind of depends on your gpu being outdated crap). I've had this happen on a self-compiled ppsspp running on a self-compiled RA (with only the gles driver option) switch to and from other cores iirc - probably a confusion of opegl<->gles. Some cores with software renderers fallbacks switched (beetle), some pretended they were running the opengl driver (dolphin), some crashed. This is not the only configuration where this happens, just a common one.

No files or tests are named. Start by tracing RetroArch's KMS input path and the main/video-renderer thread interaction described here, then check how CTRL+C is currently handled. Done means CTRL+C reliably exits a renderer-thread freeze without requiring a hard reset, while TTY switching and reboot behavior remain unchanged.