Implement input action abstraction in pad_handler

[Souzooka]

This pull request implements input action abstraction in pad_handler, similar to the behavior of CPadControl in the original Dark Cloud 2. Actions can be registered with an input, and then polled at a later time.

Example usage for registering an input button action:

// Associate the first input action, tentatively _0, with the circle button
g_host_interface::pad_register_button_action(host::pad_handler::button_action::_0, host::pad_handler::buttons::circle);

Example usage for polling an input button action:

if (g_host_interface::pad_check_button_action(host::pad_handler::button_action::_0))
{
  // User is pressing the input associated with the action _0
}
else
{
  // User is not pressing the input associated with the action _0
}

Analog actions work similarly, but return the float value of a particular axis instead of a boolean digital value like buttons.

A callback function can also be optionally provided as a third argument for the registration functions, or set at a later time using pad_set_button_action_callback(const pad_handler::button_action btn_action, std::function<void(bool pressed)> callback)/pad_set_analog_action_callback(const pad_handler::analog_action ana_action, std::function<void(f32 axis)> callback). Callback functions are invoked for buttons when the pressed state changes, while callback functions for analog are invoked with the axis value every frame.

Shortcomings:

• All actions are either analog or button actions, regardless of input device. What this means is that certain actions which are analog inputs (such as character movement) on gamepad may be difficult to remap from whatever we treat as the left analog stick (e.g. WASD) to another digital button.
• Currently, registering an input completely reinitializes the action_button/action_analog entry, including its callbacks. This means that re-registering an input may invalidate existing callbacks, so we may want to check to see if the entry already exists in the map and, if so, just update m_input_key and m_value while preserving m_callback.
• Registering an input action forces a mutex lock so that the value of the input can be polled; this may be slow if we register a bunch of inputs at a time, such as if we decide to just register all actions up front like how Dark Cloud 2 does it.

[raSTARgfx]

This additional level of indirection concerns me. Not only is it forcing a bunch of locking but also we now have two levels of map lookups that could probably just be optimized to one.

[raSTARgfx]

Suggestion: rather than limit yourself to the design decisions of a 20 year old game with this CPadControl interface (which you've modified the behavior of anyway). Why not just modify the pad/host interface to do what you want?