Allow more than 16 buttons to be defined

[lewisfff]

It would be cool if the button definitions were dynamically mapped instead of hard coding 16.

For some controller ideas I have for example 20 buttons and it looks like I can't do this at present

[progmem]

Hi! So, the limit of 16 buttons was chosen for a couple different reasons:

• Initially, USBemani was developed around supporting a limited controller set.
  • Out of the games that it tries to support, a limit of 16 buttons would usually be enough.
  • That being said, there's no technical reason why this can't be larger.
• Buttons and lighting have a bit of an interesting relationship in that most buttons have some form of LED or bulb in them.
  • Supporting more than 16 buttons means also supporting more than 16 "traditional" lights.
  • We have a limitation of 63 bytes we can work with in the report, reserving one byte for a report ID for future use, so as long as the combination of lighting data doesn't exceed this (8-bit RGB channels + traditional lighting channels), this should be fine.
  • At 16 RGB channels (48 bytes), there's still plenty of room to support 32 on-off channels.
• The Windows game controller panel will only display a max of 16 buttons.
  • This is just a display limitation; DirectInput can handle a maximum of 32 buttons.
  • Anything higher than 32 buttons runs into DirectInput limitations. You run into limitations with games at this stage. I have a flight stick for Elite: Dangerous, which has a limitation of 32 buttons. If someone can show me a functioning nostalgia sim, then maybe I'll consider some mechanism for something higher.
• 16 buttons matches the eAmuseCloud descriptors used for Konami's cloud offerings.
  • Based on that, I don't see a need to support >16 buttons in those cases, and I'd like to keep the EAC descriptors with as minimal modifications as possible for documentation purposes.
• 16 buttons packs very nicely, requiring only a single variable.
  • 32 buttons can be supported in a similar fashion.
  • Anything higher requires multiple variables, and I really don't want to do this if it can be avoided.

While I personally don't see a case where a user would need more than 16 buttons, from a technical perspective I also can't find a good enough reason not to. With that being said:

• I want to limit this change to only the USBemani USB descriptors.
  • As noted above, I don't want to change the EAC descriptors.
  • PS2 is limited to 16 buttons because of Sony's format.
• The input capture memory can be expanded to a uint32_t with what should be no issue.
• The way inputs are captured may need to be adjusted, and as it stands there might be a faster way to do it.
  • avr-gcc, when it comes to bitshifting, is a little...annoying. We would need to make sure that the mask is constructed in a 32-bit value and the bit shifted up once with each scan.
  • Depending on how the mask is generated, the AVR can end up with a zero-mask that we're ORing in.
• The descriptors (both the C packet representation and the descriptors themselves) can be modified to work with up to 32 bits of memory.
  • Windows descriptor caching will be a little annoying here, and a cache clear might need to be performed.

Let me think on this some and review the current state of code. As it stands, there's a fair few things that I'd like to address across a number of areas, so I'll take this in consideration as well.