Organizing the drm backend to only use one api to allow for more devices

[MrMugame]

Notes

• Sorry for the awfully long single commit, the way I developed this, that was the only way
• This PR is kind of a WIP and maybe even a XY problem
• Theses changes are theoretically breaking

---

The Problem

So I'm currently using a raspberry pi and a small display plus a rotary encoder to built a little device. I'm using raylib for the software, because of the direct drm support, so I can avoid X11. Problem is: raylib doesn't support rotary encoders when selecting PLATFORM_DRM. This is because rotary encoders basically either have one relative or one absolute axis, but the way rcore_drm.c is detecting devices doesn't allow for that, it required at least two axes.

Approaching the solution

So the problem now is how one classifies the different kind of input devices into the categories raylib exposes. (This isn't standardized, you probably know that). The rotary-encoder linux driver allows for either one absolute axis or one relative axis. Absolute axes are annoying, because rotary-encoders don't have a physical stop, so you always have to deal with weird wrapping issues. Relative axes are annoying, because gamepads don't typically have a relative axes (and thus raylibs API doesn't really allow for it ....). I for now decided on an absolute axis.

What this PR changes

• The old thread code is removed, because this wasn't used anymore and thus has no reason to exist (There were also some errors, like the file descriptors not getting closed)
• The stdio keyboard is now not getting initialized if SUPPORT_SSH_KEYBOARD_RPI isn't set
• The gamepads are now handled using the evdev API and not joydev/joystick API as that API is old and the new other one gives us more control over what is a gamepad
• The detection of evdev devices has been changed to take account for the gamepads. This would be the breaking change. It also allows for single axis devices now. (The only thing that's more restrictive now is keyboards now require more than just a SPACE key)
• The polling has been factored out into separate functions

Open Problems

• What is USE_LAST_TOUCH_DEVICE supposed to do? As it is definitely not doing anything currently (see comment)
• Should single relative axis devices be allowed? Should they be gamepads?
• What about other devices like accelerometers, etc. ? Maybe a separate special IO API?

[raysan5]

@MrMugame This is a big review! It looks good to me but maybe @michaelfiber fiber could also take a look, afair he was working on something similar.

[MrMugame]

So I just noticed that with the default deadzone of 10%/5%, the rotary encoder is losing steps ... which is a problem. I'm gonna mark this as draft now, because there too many open questions imo.

[MrMugame]

Ok, decided to handle the rotary encoder separately and from the things I wanted to change the PR seems complete, not gonna add anymore changes to this PR

[raysan5]

@MrMugame Thank you very much for all the work put on this improvement! It looks great!