WIP: Vulkan renderer

Still WIP, but this is a working implementation of a Vulkan renderer for Weston. It is heavily based on the current gl-renderer. As of this point can be run with the DRM and wayland backends, tested on Intel platforms.

It implements a similar rendering path with damage tracking, and a similar pipeline creation setup to what the gl-renderer did with its shaders. It is currently able to render shm and dmabuf (imported from OpenGL/Vulkan clients) applications in the compositor. It can also already run the full regular Weston desktop-shell, with blending and rendering the client decorations when run with the Wayland backend. Surprisingly, Xwayland and some X clients also seems to work well.

One of my motivations for doing this is for Weston to have a very low Vulkan requirements renderer implementation, so that it can work with any Vulkan implementation. In particular, so that it can be enabled as early as possible in new and upcoming Vulkan drivers. Working with recent hardware that is starting to be Vulkan-only or Vulkan-first, one of the issues I encountered was that enabling Wayland was a challenge due to needing to run compositors with Zink (increasing its minimum Vulkan requirements to get started) or higher Vulkan versions.

Major pending features are synchronization and proper handling/exposing of supported formats. These are right next but I felt even with this missing it is a working baseline worth sharing already.

There will still be refactor/cleanup to follow, so please don't consider the code too much in detail just yet. There is still some copy and paste to be cleaned up.

I think one of the most interesting parts worth discussing is the backend integration. Since there is no gbm_surface integration with Vulkan, I am currently allocating separate BOs with a new path in drm-gbm. On that I would appreciate some feedback. I guess even the GL renderer could move to a surfaceless, separate BOs backend, and this could be unified some day? For the Wayland backend integration, I'm using a different rendering path as a regular application Vulkan swapchain. I think this is ok for now, since the GL renderer mostly uses application-style EGL contexts anyway. But it could possibly be also integrated and unified with the same separate BOs flow, as I also tested with the included "weston-simple-dmabuf-vulkan" demo client.