aquabsd.alps: Offload framebuffer rendering to windows from the vga device

[obiwac]

Before the aquabsd.alps.win device existed as it does now, I needed a way to test the aquabsd.alps.vga device as an X11 client, so I wrote a quick backend (the X11 backend) which just created a window and drew to it using the MIT-SHM extension. Now that aquabsd.alps.win exists, this means there's a lot of redundant code between the two; this PR aims to merge the X11 backend of aquabsd.alps.vga into aquabsd.alps.win.

The advantages of this are:

• Greater flexibility for programs/other devices using aquabsd.alps.win, as they may now benefit from proper framebuffer support (e.g. for platforms which don't have the graphical acceleration capabilities to create EGL contexts in windows using aquabsd.alps.ogl).
• Greater code reuse.
• Simplified library interaction. E.g., all UI backends use the aquabsd.alps.win API for the OGL & FB backends rather than two different ones.

What needs to be done:

• Commands for creating and interacting with framebuffers in windows.
• Restructuring of the aquabsd.alps.vga device. (I'm not yet sure how I want this to work; should it be completely removed and the aquabsd_vga backend somehow merged into aquabsd.alps.win, should it be a replacement device for aquabsd.alps.win, ...?)
• Simplification of the UI library to not worry about aquabsd.alps.vga anymore (depends how I decide the above point is gonna work).
• Commands to show/hide cursor (should probably use this occasion to get to implementing that system for changing cursors to anything, not just show/hiding?).
• How should all this work with resizing?
• Rewriting of programs which currently use aquabsd.alps.vga.

[obiwac]

I'm not yet sure how I want this to work; should it be completely removed and the aquabsd_vga backend somehow merged into aquabsd.alps.win, should it be a replacement device for aquabsd.alps.win, ...?

I'll add the aquabsd_vga backend into aquabsd.alps.win and retire aquabsd.alps.vga. Having the client handle different backends goes against AQUA's device philosophy, and I'll anyway end up having a Wayland window backend in the not-too-distant future.

This also means that aquabsd.alps.ui will only need to concern itself with a generic aquabsd.alps.win device.