Translate back-button to escape-key on Android, quit if Android back-button is pressed 3 times within 1 second

[Robyt3]

Translate the Android back-button to the escape-key, so it can be used to navigate back in menus, open/close the ingame menu, close the editor etc.

Trap the Android back button by setting the SDL_ANDROID_TRAP_BACK_BUTTON hint, so it can be handled in our code reliably instead of letting the system handle it.

Interpret fast repeated presses of the back-button (3 times within 1 second) as a quit-event, so the app can be quit cleanly and quickly without using the UI. The client settings are otherwise not saved if the app is closed by minimizing it using the home button and waiting for the OS to kill it or by discarding it in the recent apps view.

Checklist

• [X] Tested the change ingame
• [ ] Provided screenshots if it is a visual change
• [ ] Tested in combination with possibly related configuration options
• [ ] Written a unit test (especially base/) or added coverage to integration test
• [ ] Considered possible null pointers and out of bounds array indexing
• [ ] Changed no physics that affect existing maps
• [ ] Tested the change with ASan+UBSan or valgrind's memcheck (optional)

[heinrich5991]

The back "button" is swiping from the outer edge of the screen on newer Android systems with gestures enabled. Doing that 5 times within one second is probably impossible. Perhaps twice would suffice?

The client settings are otherwise not saved if the app is closed by minimizing it using the home button and waiting for the OS to kill it or by discarding it in the recent apps view.

Could we save the settings when we become inactive?

[Robyt3]

The back "button" is swiping from the outer edge of the screen on newer Android systems with gestures enabled. Doing that 5 times within one second is probably impossible. Perhaps twice would suffice?

I think 2 presses in 1 second are a bit too easy too trigger accidentally with a hardware button though. Can we compromise on 3 in 1 second? Making this dependent on whether the back buttons is hardware or virtual seems overkill, although possible.

Could we save the settings when we become inactive?

Probably, we could try to save them whenever the app becomes hidden to the user, but there is no way to do it reliably if the user/system kills the process. That could also happen during the saving process, though this should be fine since we write to a temporary file first. However, I'm not sure if this could lead to threading issues at the moment, since the onStop callback runs in a different thread then the native main function. If I understand the SDL code correctly, the native thread is paused in onStop (when the app is hidden) by blocking it on a semaphore in SDL_PumpEvents, but we don't reliably know when the native code has been paused to save the config after that. Maybe we shouldn't pause the native thread while the app is hidden, since that would timeout the player from the server if they minimized the app for too long. I'd do that separately though, so this PR is only about back-button behavior.