Add gamepad support for feathers / headless widgets

[alice-i-cecile]

What problem does this solve or what need does it fill?

Throughout the bevy_ui_widgets codebase, we have convenient baked-in interactions, like updating a checkbox in response to Enter if it's focused. See checkbox_on_key_input for an example of this.

This should work with gamepads too! Bevy is a game engine, and this is nice for accessibility in other apps too.

What solution would you like?

We should also listen to Gamepad::South from any gamepad in the same way.

This is common enough that I would ideally like to abstract this into an intermediate event.

What alternative(s) have you considered?

Simply implementing this directly is fine, but this is a common pattern that deserves a bit more encapsulation to make it easier to refactor and use in end user widgets.

Additional context

Related to #435, but we shouldn't block on that. If sane, non-configurable defaults are good enough for keyboard, they're good enough for gamepad.

[viridia]

I have a plan for this, but it depends on BEI.

[viridia]

Note that the headless widgets already contain part of the solution: we have defined events for remote-controlling the widgets, like SetChecked and SetSliderValue. These events are currently unused, but their purpose is to allow an input mapper to dispatch events to the widgets.

Without an input mapper, we can't do much more than this right now. Unlike keyboard, where there are clear, common, industry-wide conventions for which keys affect widget states (SPACE to toggle a checkbox for example), we can't assume that the A button or right trigger should be the button that does this.

With an input mapper in place, I had envisioned a scheme like the following:

• The developer would create an input map for each focusable widget type: checkbox, button, slider, and so on. So for example, if they wanted the left trigger to toggle the checkbox state, they would create a CheckboxMap action map that dispatches a ToggleChecked EntityEvent to the current focused entity when the left trigger is pressed.
• These maps would be conditional based on the type of entity that currently has focus. So CheckboxMap would be enabled whenever a checkbox has focus.

This is a bit complex, but it has a some advantages. The main one is that widget actions and global actions can co-exist, but not collide. Thus, if a checkbox is focused, you can still press the B (cancel) button to dismiss the current settings dialog. Since the checkbox does not recognize this as an action, it does not consume the event, which means that the event can be processed normally.