[Feature request] libretro api : possibility to assign more retropad buttons

This is kind of a duplicate of a request i did last year (https://github.com/libretro/RetroArch/issues/8209) because the goal is basically the same.

It is also kind of a duplicate of https://github.com/libretro/RetroArch/issues/6718, with a somewhat different goal in mind since that old issue was more about hiding buttons to not have them sitting randomly all around the place.

Currently, when creating input descriptors before sending them to retroarch, we are limited to assigning to those buttons/axis :

#define RETRO_DEVICE_ID_JOYPAD_B        0
#define RETRO_DEVICE_ID_JOYPAD_Y        1
#define RETRO_DEVICE_ID_JOYPAD_SELECT   2
#define RETRO_DEVICE_ID_JOYPAD_START    3
#define RETRO_DEVICE_ID_JOYPAD_UP       4
#define RETRO_DEVICE_ID_JOYPAD_DOWN     5
#define RETRO_DEVICE_ID_JOYPAD_LEFT     6
#define RETRO_DEVICE_ID_JOYPAD_RIGHT    7
#define RETRO_DEVICE_ID_JOYPAD_A        8
#define RETRO_DEVICE_ID_JOYPAD_X        9
#define RETRO_DEVICE_ID_JOYPAD_L       10
#define RETRO_DEVICE_ID_JOYPAD_R       11
#define RETRO_DEVICE_ID_JOYPAD_L2      12
#define RETRO_DEVICE_ID_JOYPAD_R2      13
#define RETRO_DEVICE_ID_JOYPAD_L3      14
#define RETRO_DEVICE_ID_JOYPAD_R3      15

...

#define RETRO_DEVICE_INDEX_ANALOG_LEFT       0
#define RETRO_DEVICE_INDEX_ANALOG_RIGHT      1
#define RETRO_DEVICE_INDEX_ANALOG_BUTTON     2
#define RETRO_DEVICE_ID_ANALOG_X             0
#define RETRO_DEVICE_ID_ANALOG_Y             1

Which means we can assign 24 different actions to a retropad controller (including its sticks), in most cases this is plenty, but i've found some cases where being able to map more actions would be awesome, those actions don't need to be mapped to an actual button when starting a game for the first time, they just need to exist as a choice when remapping through "Quick Menu > Controls".

My idea would have been to have those new entries in libretro.h :

...
#define RETRO_DEVICE_ID_JOYPAD_L3      14
#define RETRO_DEVICE_ID_JOYPAD_R3      15
#define RETRO_DEVICE_ID_JOYPAD_FAKE1   16
#define RETRO_DEVICE_ID_JOYPAD_FAKE2   17
...

Then when developping a core, you could assign an action to the RETRO_DEVICE_ID_JOYPAD_FAKE1 id, that action wouldn't be mapped to an actual button by default, but would be available to be mapped wherever the user want when going into "Quick Menu > Controls".

For a core like FBNeo, it would be a huge improvement since i could declare all kinds of macro/autofire actions (which already exist in the codebase), but also weird cabinet inputs that need to be mapped somewhere sometimes, which is why i largely prefer this over the macro mapper.

note: i said 24 actions but tbh it's more like 16 actions, because remapping a non-directional action assigned by default to a stick's direction is extremely clunky. 16 is extremely limited and for the record not sufficient for a machine like the coleco which has 18 keys on its joystick.

note 2: a retired dev made that statement:

I think the only way to add these extra inputs is to define a whole new input device type - something analogous to the current keyboard device, but just a generic 'button bank' with an arbitrary number of indexed buttons (128 or something). These could then be labelled and used however the core wants, and the frontend could map any of them to the existing retropad inputs (like we do currently with 'virtual' keyboard keys).
So someone needs to implement this 'button bank' device type - i.e. copy/paste the current keyboard type, but instead of having pre-defined 'key' inputs, make every input generic and assignable core-side (so then each of these core-assigned inputs can be mapped to retropad inputs in the frontend, like you can currently do with keyboard inputs)

Start with the RETRO_DEVICE_ID definitions in libretro.h and trace the input-descriptor and Quick Menu > Controls paths mentioned in the issue. Compare the proposed fake buttons with the suggested generic button-bank device, then define and implement a design that exposes extra core-assigned actions for user remapping without default physical mappings.