Make osk-sdl and charging-sdl more robust against upstream breakage

[ollieparanoid]

Upstream issues like https://github.com/postmarketOS/osk-sdl/issues/80 completely break our charging screen and encrypted installations.

A big source of problems is, that with the downstream kernels we can only use a framebuffer driver. Framebuffer is a deprecated API in the kernel, newer drivers use DRI/DRM (we use this for all devices running a kernel close to mainline). SDL2 supports DRI/DRM and still framebuffer, but only through the DirectFB library (for which upstream seems to be dead). Because of all that, the DirectFB backend doesn't seem to be tested well by SDL2 upstream, and regressions that are really bad for us can end up in the release. osk-sdl and charging-sdl use SDL2 to display the graphics.

So we should look into changing the workflow at some point that it never breaks for postmarketOS. @ata2001, @craftyguy and I just discussed the topic in the channel, and we had the following ideas:

• Carry a statically linked fork of the SDL2 aport, which we use for the initramfs. We only update the aport after testing charging-sdl and osk-sdl with it on Framebuffer and DRI.
• Improve SDL2 testing for DirectFB backend upstream

What do you prefer, folks? Do you have more ideas?