Generic graphics command buffer

[matthewgeorgy]

The current OGL graphics implementation uses a standard gs_command_buffer_t as its command buffer. This works since OGL is not thread-safe, and so the command buffer here is simply used to defer API calls onto a single thread. However, this scheme is not ideal, as different graphics APIs have their own concept of a command buffer which is managed on a per-API basis. Furthermore, such APIs allow for legitimate thread safety when using such command buffers, and so we need not defer calls like the OGL implementation. Since gs_command_buffer_t is decoupled from the graphics subsystem, there is no way of handling such command buffer work on a per-API basis. Currently, the user simply creates a new command buffer with gs_command_buffer_new(), and thus the graphics implementation has no way of managing it appropriately. As such, introducing a generic graphics command buffer type for the graphics interface would allow users to define their own custom graphics command buffer when writing graphics API backends.

Hence, I've introduced a new gs_graphics_command_buffer_t type that allows for this sort of behaviour to be possible. I've also added a gs_graphics_command_buffer_new() for creating such a command buffer, and I've changed the appropriate gs_graphics_XXX() functions to use this command buffer instead of the default one.

Currently, for the default OGL implementation, this new type and function simply alias to the default gs_command_buffer_t. In the future, when alternative graphics backends are implemented, a simple #ifdef/#ifndef check can be used to choose the correct command buffer type for each API. I've also tested this change with the existing gs_examples (ex_core_graphics) and haven't encountered any issues.