Unify button shortcuts

[djdiskmachine]

Break up 1 of issue #58

Suggestion was to, when in New project or Save as screens, START would move the cursor to "Ok".
Likewise, B would place the cursor on "Cancel".

I'd like to suggest the following:
Instead of moving the cursor, simply let START and B replace the function of moving the cursor to said option and pressing A

This would have a reflected behavior in the sample browser, where start allows for playing / loading samples.
I suggest to let the user exit the sample browser by simply pressing "B"

[Nine-H]

I've been thinking about the control mapping problem for a while. As we support more devices we can never know the number of keys or their layout ahead of time. It's currently kind of annoying to map macros and input separately with two different schemas in two different files, arbitrary mappings are not possible, and there are side effects from macros adding to key combinations.

We could potentially create a more flexible and robust keybinding system based on the mapping xml schema, but extended with a MOD element. Here's an example schema imagining a scenario the space bar is mapped to a modifier that makes the cursor keys mute the first four channels:

<MAPPINGS>
  <MOD src="key_space">
    <MAP src="key_left" dst="/event/toggle_mute/0" />
    <MAP src="key_up" dst="/event/toggle_mute/1" />
    <MAP src="key_down" dst="/event/toggle_mute/2" />
    <MAP src="key_right" dst="/event/toggle_mute/3" />
  </MOD>
  <MAP src="key_left" dst="/input/left" />
  <MAP src="key_up" dst="/input/up" />
  <MAP src="key_down" dst="/input/down" />
  <MAP src="key_right" dst="/input/right" />

a user may wish to set up keybinds like this to quickly mute and unmute channels during a live performance without having to navigate to the song screen or highlight specific chains.

While I believe this approach could replicate the current controls. This approach has some drawbacks/limitations:

• we'd need to enumerate all the possible actions instead of having a specific set of buttons with an intrinsic set of combos
• any action that was not global would need handlers defined for each screen to ensure that whatever happened when you pressed it made sense on that screen
• do keys that are mapped outside of a modifier but not mapped inside of the modifier still work when that modifier is held? (although maybe that could be set per-modifier with an "exclusive" property)
• I think we still need context sensitive actions like "accept" and "cancel" to maintain the LSDJ like navigation and control scheme
• I don't have any great ideas about how to handle mapping controls for specific contexts like the file or text input dialogs

[djdiskmachine]

Interesting idea, let's consider it for a 1.4 release or later.
This issue was intended specifically for the naming screen prompt, please create a new issue with your suggestions =)