Poll all 16 buttons in a single retro_input_state()

[heuripedes]

It'd be nice if one could pass something like RETRO_JOYPAD_ID_ALL as the id parameter of retro_input_state() so that the frontend would return a bitmask containing the state of the 16 buttons supported by the libretro api.

This can be implemented in v1 without ABI/API breakage, maybe a RETRO_ENV_GET_CAN_* query could be used to detect this feature.

[Alcaro]

I could swear we already had an issue for this? In fact, I could swear it's what made Twinaphex authorize an ABI bump?

Advantages of doing this:

• In theory, it's slightly easier, but you get that same advantage by copypasting a function from another core.
• In theory, it's slightly faster due to 15 less function pointers - in practice, it's too small to be measurable.

Disadvantages:

• Changing libretro is not a cheap operation - fronts initially won't support that, so you need to either hold a dependency on a really fresh front, or make a fallback to the old mechanism.
• Multiple ways to do the same thing is generally a source of confusion.

I'm not convinced that the advantages outweigh the disadvantages.

I agree that we need to rewrite the input handlers for libretro v2, but I'm not happy with neither the existing method nor your proposal. I want v2 to be an event-driven architecture, so we can get rid of the polling entirely. It's the only way to scale to large numbers of keys (RETRO_DEVICE_KEYBOARD).