[WIP] SDL_gpu Vulkan

Hello! I wrote the Vulkan implementation of FNA3D, and SDL_gpu is of great interest to us, so I figured I would help get the Vulkan scaffolding going to develop thoughts about the API structure. My initial goal is to get to a clear screen, since the shader system is still being worked on. I got device initialization and command buffer creation working, and I'm starting to take a look at swapchain initialization and texture creation, which also involves setting up a memory management strategy. A few thoughts about the API so far: - `GpuCreateDevice` should probably take a debug mode flag - Vulkan lets us load an optional validation layer which is _very_ useful for debugging purposes on both the backend and application side. I imagine other APIs are similar. I actually went ahead and added this in because it's so useful, but obviously this API change will need to be approved. - I'm not convinced about `GetBackbuffer` and `Present`. Vulkan expects you to set up a semaphore between command buffer submissions and presentation calls to avoid blocking, so having these calls not involve the command buffer means that the backend will have to track accesses of the backbuffer on the command buffer. The naming of `GetBackbuffer` feels awkward to me too because modern APIs use a swapchain and not a backbuffer. - Vulkan actually requires you to recreate the swapchain if the presentation strategy changes, so having this be an argument to `Present` could be a problem. Setting swapchain parameters should probably be its own API call. - A potential solution for the above issues from another graphics system I developed: acquire a swapchain texture using a command buffer as an argument, and then automatically queue up presentation upon submission of that command buffer. This has worked fine for every use case I've encountered and it's very little burden on the user. - I'm not sure about having fences directly exposed on the public API level. In Vulkan we can only submit one fence per command buffer anyway, so most of the use cases for fences just involve caring about if the command buffer is done processing or not. It's definitely useful to be able to know that, but leaving fence management completely to the application side feels like an unnecessary burden to me. - Creating resources like textures and buffers in Vulkan involves setting up a manual memory management strategy. In Metal, the application can specify a storage strategy upon creation of a resource. I think mirroring this might be a good idea for SDL_gpu - it simplifies the implementation of the Vulkan backend significantly because it doesn't have to make assumptions about what kinds of memory should be allocated for different kinds of resources, and the application can be made aware of scenarios like device memory running out. - From the application side, specifying a string label for most of the API calls is a bit burdensome. At least for my own use cases I'm not going to care much about granular labeling, so I think a push/pop system would work a lot better here. Sorry for the massive wall of text, hopefully these suggestions can lead to some fruitful discussion. I've never contributed to SDL before so suggestions about code style or appropriate data types are appreciated. My CMake changes will probably need a revision, I just wanted to get this building and I'm not sure how you want the _gpu configuration stuff to work.