[WIP] Expansion of button controls for intent-based control modifications

[cclark25]

This PR contains code I have written for a controls mod for the 2ship2harkinian application, and I wanted to share it here in case it is useful to anyone else. Currently it is branched off of the commit used by 2ship.
This corresponding branch of 2ship uses these changes: https://github.com/cclark25/2ship2harkinian/tree/IntentControls

The primary goal of this branch is to allow the addition of an arbitrary number of button controls, for the sake of defining controls based on their intended usage rather than a set of limited global buttons.
For example, instead of a game using the A button for jump, roll, and talk, this will instead allow each of those controls to be optionally defined separately for more granular control mapping.
This is currently very difficult in the libultraship library because all buttons are defined as a 16bit bitmask, only allowing 16 unique buttons. This PR addresses that by adding on special button mapping functionality, which utilizes a separate 16bit button ID value and 8bit "pressed" state to track whether a button is pressed or not. This effectively allows up to 2^16 - 1 (0 is reserved) additional buttons.

In addition, these control checks will be managed by a collection of function pointers, allowing the special control logic to be customized and swapped in/out per controller.

These code changes are currently functional.

[briaguya-ai]

all buttons are defined as a 16bit bitmask

this is only true if the port doesn't define CONTROLLERBUTTONS_T to be something else

libultraship/include/libultraship/libultra/controller.h

Lines 84 to 86 in 5849d3a

	#ifndef CONTROLLERBUTTONS_T
	#define CONTROLLERBUTTONS_T uint16_t
	#endif

as long as whatever type the port defines as CONTROLLERBUTTONS_T is capable of bitwise logic it should "just work" with the existing code

that being said the implementation in this PR would likely offer more flexibility - it just also introduces quite a bit of complexity

i'm curious as to what other people think about the complexity/flexibility tradeoffs with this implementation

[cclark25]

as long as whatever type the port defines as CONTROLLERBUTTONS_T is capable of bitwise logic it should "just work" with the existing code

That is a fair point. Although the CONTROLLERBUTTONS_T could really only be replaced with a uint64_t type since the controls are often referenced in C code. That would provide a maximum of 63 different buttons, with 14 of those already reserved for the more traditional control buttons.
That may be enough for most cases.

[cclark25]

Hmm I think I may have been mistaken about uint64_t being the maximum. In GCC there is is a __uint128_t type. If that can be used as CONTROLLERBUTTONS_T it would push the need for a more complex solution even farther back.

[cclark25]

Alright the __uint128_t type does not work because it isn't supported by things like std::to_string.
I also tried using a class with overridden bitwise operators, but that still produces incompatibility issues.

This confirms that 64 bit button bitmasks would enable the maximum number of additional button mappings without a more complicated solution such as the one I have implemented. That should probably be enough for most use cases.