gamecontrollerdb issue braindump

after seeing https://github.com/HarbourMasters/Shipwright/issues/3879#issuecomment-2002552704 i decided it's probably a good idea to write down some thoughts around gamecontrollerdb issues

the main issue is id conflicts. there are multiple controllers that end up with the same id for gamecontrollerdb. the upstream repo refuses to replace existing mapping strings, and even if they did that wouldn't be a good solution because it would mean other controllers are broken

one potential solution would be to move away from using SDL gamecontroller, and just use joystick instead. i don't think this is a good solution to this problem as it would complicate a lot of the gamecontroller stuff we take for granted. we'd basically need to create the joystick and then try to create a gamecontroller to support gyro etc. and if that doesn't work fall back or something. we'd also lose the ability to know button names when in joystick only mode. overall this would move the complexity into a place that feels hard to maintain.

i think there are a few things we can do to provide a solution that works
* maintain our own fork of gamecontrollerdb, and ship our db text files from there
* right now we pull this in at build time, we could also allow updating the db file at runtime (opt in)
* not quite sure how this would work in appimages but it's definitely something we can figure out, something as simple as "use a file that's a sibling to the appimage file if it exists, if it doesn't fall back to the file inside the appimage"
* we could provide multiple db files - default to using the ones that our players use most commonly (mayflash adapters as n64 instead of snes for example) - but offer alternatives for people to try if their controller is showing up as the wrong thing - and with runtime switching (even if game restart is required)

i think this could change the support flow from
player my controller isn't working (turns out it's not in the db or has the same id as a different controller in the db)
support: ask player to do the thing to make a mapping string and share it
player: makes mapping string, gets it working in game after manually changing file, sometimes shares string back so it can be PRd to the db
support: tries PRing string to upstream DB, maybe gets it accepted maybe doesn't

to

player: controller not working
support: get mapping string from player, updates fork of db, any other players with the same controller can now just hit the update db button in game to get a db that works for them

closing thoughts
* maintain fork of db
* keep track of id conflicts, resolve them towards most commonly used controllers by players of soh
* in the case of multiple controllers with the same id being used, have alternative db files with the alternative controller
* if this gets overwhelming, we could even set up some scripting to *generate* the db files instead of having multiple giant text files checked in
* provide a way to pull updated db at runtime