Add better binding scheme management.

[duhrer]

Currently, we have a single "default settings" scheme that users can choose to overwrite their bindings with.

It would be more helpful to add the ability to choose from a range of built-ins, and also to store multiple schemes.

Users should be able to name their scheme sensibly, and switch between their schemes on the fly (perhaps with an action for that).

For legacy compatibility, the default selected schema should be gamepadConfiguration, which would just become the first of many possible user binding schemes.

[duhrer]

One key concern here is distinguishing page navigation from modal navigation somehow.

In current testing, I have been binding the d-pad to send individual arrow keys. Although this has been adequate so far, it's confusing, in that the d-pad is largely non-functional when navigating most pages (which tend not to support arrow navigation).

One solution is to have two "contexts", page context, and modal context, and to have separate schemes for each. This either requires double data entry (same bindings in both contexts) or some means of indicating that the modal scheme should "follow" the page scheme.

Another solution is to add a new type of "wrapper" action that is conditional, i.e. with one sub-action when a modal is open (modal context), and another when no modal is open (page context). By omitting a sub-action in one context, we could make controls that only work in one context. I like this idea in particular for the d-pad and thumb sticks, but will need to give some thought to the editing UI, as this type of binding will be more complex to add/edit.

We could also simply limit page-level actions (next tab, new window, et cetera) so that they cannot function when a modal is open. This would mean that the "combi" bindings are really only needed when there are two distinct actions for a given control. and that (for example), you wouldn't have to create a "combi" button yourself to ensure that you don't accidentally close or navigate away from the window you're controlling when a modal is open.

However we choose to model this, we might handle the data entry by presenting two columns for each binding, one for the page, one for modals. We could also present two rows or sub-headings, same idea.

[duhrer]

I'm thinking of leaving schemes and scheme management out entirely for version 1.0, with the exception of perhaps a "restore defaults" button.