Support `Back` button/`KeyCode` on Android

[MarijnS95]

Started playing about with VirtualKeyCode on Android, and it seems there's no mapping for KeyCode::Back which would be needed to handle a graceful app exit (or going to the previous page) when the user presses it. The implementation for VirtualKeyCode::Back reads:

winit/src/event.rs

Lines 962 to 964 in f04fa5d

	/// The Backspace key, right over Enter.
	// TODO: rename
	Back,

So I don't think we should add a new Back VirtualKeyCode and rename existing uses to Backspace, as that's really hard to notice for end-users upgrading their winit. Perhaps we can piggyback NavigateBackward but android already supports that as KeyCode::NavigatePrevious:

Keycode::Back => Some(VirtualKeyCode::NavigateBackward),

How do you think we should go forward?

Originally posted by @MarijnS95 in #2226 (comment)

[kchibisov]

@MarijnS95 is this still an issue?

[MarijnS95]

@kchibisov I don't see Keycode::Back being handled anywhere in Android's platform_impl, so I guess not?

[MarijnS95]

@kchibisov note that while searching for VirtualKeyCode I could still find some references in src/platform_impl/linux/x11/events.rs even though it was renamed to Key in #2662. This module doesn't seem to be referenced anywhere, was the file not deleted while X11 was refactored?

EDIT: Turns out that refactor happened in #2662 :)

[kchibisov]

I guess everything is fine, right?

[MarijnS95]

@kchibisov it's not exactly fine as we cannot handle that keycode yet, it's not mapped.

What's worse, we don't have a way to optionally mark the keycode as used at runtime (e.g. given how inconsistently we're forced to handle volume keys now since #2748) as users would likely want to back out of some menu stack. Once they are at the bottom of the stack, they will set handled=false on Keycode::Back (probably via a KeyEvent extension trait) so that Android handles it instead and leaves or stops the app.

[kchibisov]

But you can define a filter mask on event loop builder whether we want to accept or not? Like HashSet<Key>. Could use something else, but setting a filter mask for events user want to handle or not sounds 'sane'.

[MarijnS95]

Was that built already? Your comment sounded like a suggestion but I'll check it out. Most important question: can we change the contents of the HashSet at runtime after building the event loop? As explained above that is vital to supporting these things.