Add graphics subsystem

[facekapow]

Adds a graphics subsystem plus a BGA driver to provide a default renderer. Since the BGA backend has to perform calculations every time it's going to find a pixel, it's fairly slow at rendering, but it's decent enough.

Right now, graphics can be loaded with runtime.graphics.enableGraphics() and pixels can be manipulated by fetching them through runtime.graphics.screen.get(x, y) which will return a pixel from the backend. The backend should return a pixel with getters and setters for r, g, and b.

This is basically as thin as possible of a wrapper around multiple possible graphics renderers (BGA, virtio-gpu in the future), to be able to abstract direct access to the video buffers, providing the most basic functions (enabling graphics, pixel manipulation) allowing higher level functions (image drawing, printing text, shape drawing, etc.) to be implemented on top of that.

However, this should be refactored into an optional module later, along with other things.

[iefserge]

@facekapow this looks very good, nicely abstracted interface 👍

But.. in general case I'm afraid it will be too slow for a good performance, especially on large resolutions (i.e using virtio).

Should we expose the raw buffer with the attached info about data format? In this case drawing library (or maybe window server kinda thing here) can work directly with the buffer knowing its format and can refuse working with buffers it doesn't support.

Basically it would be abstracted at the higher level, graphics lib instead of a driver. We should get really nice performance this way and can support multiple graphic devices.

[facekapow]

I've made the raw buffer accessible through runtime.graphics.displayBuffer. Renderers should attach an ongetbuffer method which returns the display buffer. runtime.graphics.screen now just contains information about the current display format (width, height, bitDepth, bufferFormat).