Draft: Vulkan WDDM2 device support

This is a placeholder MR to hold a few patches from my RADV branch and maybe get some discussion going. As with everything in the runtime, I'm trying to take a light approach at first. So far, this branch just has WDDM2 device enumeration and support for a new vk_sync type for WDDM2 monitored fences.

For device enumeration, I added a vk_wddm2_adapter_info struct which gets populated with a couple of common queries that are available starting with WDDM 2.0. This gives the driver the PCI info so that it can quick-reject the adapter before actually cloning its own handle and doing any additional queries. It's unclear how much of this we want in common Vulkan code and how much we should just tell drivers to call D3DKMTQueryAdapterInfo() themselves. For now, I went with roughly the same information as is in drmDevice.

There's also some housekeeping that needs to be done before this can land:

1. We need to figure out how we want libdxg loading to work and what we want the meson bits to look like. Right now, it's linking against libdxg but on actual Windows, we want it to load gdi32.dll. It's also unclear if we actually want to link against libdxg or if we want to dlopen it at runtime. libdxg.so not a big library so making it a core dependency on Linux is certainly tractable but I can imagine it giving distros a bit of heartburn.
2. (#11415) We need to figure out how to sandbox the platform headers. Right now, we define VK_USE_PLATFORM_FOO globally. This means everything that includes vulkan.h may also pull in Xlib.h or windows.h and those headers pollute badly. In particular, XLib.h defines Status and that conflicts with the WDDM headers. We don't want to pull in windows.h anywhere it's not strictly needed for similar reasons. Really, the only thing that should be setting VK_USE_PLATFORM_FOO is the WSI code, the semaphore/fence code, and a few driver bits that deal with memory import/export.