OpenGL command buffer recording optimizations

[devshgraphicsprogramming]

Description

Right now cmd buffer records commands into an std::vector making little use of the command pool's memory blocks except for placing variable length arguments into it, it also uses the GeneralpurposeAddressAllocator which is the most robust but also the slowest.

Furthermore it records the OpenGL commands' arguments it would like to perform, but leaves out the state caching to the state tracker in the submission queue thread. In Vulkan (and Nabla) command buffers always start out in the initial state, so its possible to use the state tracker up-front when recording and only record the OpenGL commands that will actually be needed (this has a huge impact on binds).

Solution proposal

• Use the OpenGL state tracker locally within the context of cmd buffer recording (one tracker per cmdbuffer).
• Only record the commands that will result in an actual state change
• Instead of using a member vector, encode the commands as a linked list with backing memory provided by the pool
• Use a PoolAddressAllocator for the commands instead of the Generalpurpose, and whenever unbounded length arguments to a command are possible, split them up into more linked list nodes

Additional context

Only do it if profiler shows a lot of time spent in commandbuffer recording.

[devshgraphicsprogramming]

@AnastaZIuk at some point this will be given for you to do

P.S. its somewhat relevant to making an ICPUCommandBuffer

[devshgraphicsprogramming]

Probably a good idea to implement descriptor pools properly as well.

[devshgraphicsprogramming]

getting done as part of #345