c/render: Use its own command pool

Currently, there is a single command pool in the vk bundle, shared by everyone. Since command pools (and command buffers allocated from those pools) can only be used on one thread at a time, this requires locking. However, the main point of having these annoying command pool things in the first place is that you can use one for each thread/lifetime/area in the app and avoid the overhead of the locks (both computational and cognitive).

In this change I have given the rendering bits of the compositor its own command pool. Instead of allocating and freeing a command buffer every frame, a single command buffer is allocated from the pool during initialization, and the pool is reset at the beginning of each frame. Normally, multiple pools would need to be used, but this is not necessary in monado because frames are serialized (as far as I can tell). The TRANSIENT and ONE_TIME_SUBMIT flags have been added, which can allow for some driver optimizations. The render code no longer takes out the command pool mutex. The shared command pool is still there for a few remaining places where vulkan work needs to be done outside the compositor.

I used the command buffer vulkan helpers when possible, but I would maybe propose the idea of removing them, since they aren't really wrapping much at this point. The C macro helps a lot and it's a bit easier to see the Vulkan details in front of you instead of needing to switch back and forth between the helper.

Later, I think it would be cool to apply and document some constraints like "the queue is only accessed in functions XYZ, the render_resources command pool must only be accessed in layer_commit from 1 thread" etc.