Draft: st3m: offscreen rendering

Alternative to !222 (merged) , potential solution to #77 (closed), follow up to #28 (closed)

The exact API is in progress, but the general idea is:

1. User code allocates a Texture and draws to it however it wants, currently we automagically provide a Context for each Texture.
2. User code calls Texture.draw() in Responder.draw()
3. The Texture state is never zeroed by the system, allowing for partial redraws. Worms has been moved to use this API as an example. Gay Drums is a great candidate to test against this API.
4. Transitions, double buffering, overlays (ie. general compositing) continue to work.

Things to figure out:

1. Can we make this simpler for users, ie. allow to easily define apps that just want a persistent ctx for full screen? An extra subclass of View/Responder which always gets such a texture allocated, and users don't have to implement draw(), just think()?
2. Why is texture drawing so slow? Currently we only get around 10 FPS when copying an empty texture. Am I using ctx_draw_texture and friends wrong? I'm not sure about the intended API with eid, I expected to be able to allocate an eid once and reuse it while modifying the buffer.
3. I tried using RGB565_BYTESWAPPED instead of RGB8 for performance but that broke horribly. Not sure what's up with that.

Known issues:

1. Textures are currently always full-screen, but that is easy to fix.
2. There's some glitches on the edges of a full screen texture. Off-by-one somewhere? Or is my apply_transform call wrong?
3. Simulator needs to be updated for this.

Possible future use:

1. Non-full-screen-sized textures can be used for other purposes, like sprite graphics.
2. This allows non-ctx access to graphics, eg. pixel graphics or alternative rendering engines.

cc @pippin @moon2