ash: Some _device_ extensions are loading (and failing) _instance_ functions via `get_device_proc_addr()`

Found a couple extensions that are erroneously loading all functions through get_device_proc_addr() despite containing some instance-level functions (i.e. not taking a device or device child as first argument, see also fn function_type() in the generator for fishing this out in a crude way), which cannot be loaded. Concretely found these extensions (by looking for explicit PhysicalDevice argument, and later validated using the generator):

• VK_KHR_device_group: #631
• VK_EXT_full_screen_exclusive: #399
• VK_KHR_swapchain (new get_physical_device_present_rectangles): #629

Quick solution

Unfortunately the fix (a pattern which we apply more rigorously in other extensions) implies a slower path for device-level functions which now imply an extra dispatch table per device, “injected” by the ICD. Worse, it’s a breaking change so it might be about time to start thinking about ash 0.38.

Long-term correctness

As for the fix itself, I’ve said it before and I’ll use this issue to track it: I’d rather have the generator distinguish instance-level and device-level extension functions, either in the loader or via separate *Fn structs entirely (anything to force us to load both in a separate way). @oddhack what’s the desired way to figure this out if a function operates on device (or childs thereof)? I’m not confident this hardcoded list of "VkDevice" | "VkCommandBuffer" | "VkQueue" for the first-parameter-type will hold, does it need an extra attribute in vk.xml?

https://github.com/ash-rs/ash/blob/a9fbc7147bd2eef124d8b2153e94bbf313885420/generator/src/lib.rs#L561-L566

Random weirdness

VK_KHR_device_group_creation, added in #630, has a function named fn device() that returns vk::Instance 😅