No FBO support today

[iamgreaser]

Pretty much reliant on #166 to be useful, but could possibly be done before that.

Gory details of what FBOs actually are: https://www.opengl.org/wiki/Framebuffer_Object

Suggested API, which will probably be revised:

• result = client.gfx_fbo_available(): Returns true iff GL_EXT_framebuffer_object is supported.
• fbo = client.fbo_create(w, h): Creates an FBO with the given dimensions. Creates a colour attachment and a depth-stencil attachment.
• client.fbo_use(fbo): Use the given FBO for rendering. If "fbo" is nil, render to the screen instead.
• client.fbo_writeback(img, fbo): Writes the result of the FBO to the texture in question. This writes to the pixels[] array and marks the image dirty so it can be recommitted to the GPU. Will probably use a PBO for this.

We should also allow use of "fbo" references in place of img when blitting to the GPU, so we can avoid a redundant back-and-forth transfer. That is, client.img_blit and client.va_render_* will need to accept "fbo" references into their hearts.

Due to the fact that we garbage-collect image objects, we cannot just simply bind an image to an FBO.

[iamgreaser]

Should probably mention what we have now:

• All functions mentioned EXCEPT fbo_writeback. fbo_create has a third option to choose whether you want stencil info or not, just in case someone has a GPU that can handle FBOs, but not with a shader-readable GL_DEPTH_STENCIL attachment.
• client.img_blit now accepts an FBO and uses GL_TEXTURE1 for the depth buffer info.

FBO support is still required for VAs... and map_render once we get around to supporting textures with maps.

Question for VA support: How do we handle FBOs being passed as textures?

I suspect we'll have to make it so if the FBO is passed twice in a row, the second instance is the depth attachment; otherwise we only use the colour attachment.

[iamgreaser]

VAs now accept FBOs, but the depth attachment is still unused.