Add VK_KHR_external_memory_fd extension support

[IntrepidPig]

This is my go at adding support for the VK_KHR_external_memory_fd extension. There are a couple things I'm unsure about though:

1. That this is a necessary addition. Is the end goal of ash to have all possible extensions supported this way?
2. The storing of the device handle in the extension struct. I suppose this is because it's a device specific extension, so it's only guaranteed to work with with the device it was created with.
3. The specificity of this extension to unix. As far as I know, file descriptors are unique to unix alone, so it makes sense to put this extension behind a unix feature flag.

[Ralith]

That this is a necessary addition. Is the end goal of ash to have all possible extensions supported this way?

Yes, though it might be interesting to explore auto-generating this higher-level code too.

The storing of the device handle in the extension struct. I suppose this is because it's a device specific extension, so it's only guaranteed to work with with the device it was created with.

This is indeed conventional, in part just because it makes the extension more convenient to use, and enables an interface similar to ash::Device. A reasonable alternative would be to fold all extensions into the device and just panic on calling an unloaded one, but this is a little less footgunny.

The specificity of this extension to unix. As far as I know, file descriptors are unique to unix alone, so it makes sense to put this extension behind a unix feature flag.

You might have noticed that other OS-specific extensions (e.g. various surfaces) are not similarly guarded. Applying such a guard forces downstream code to apply similar guards when they could otherwise get away with dynamically unreachable code. While it's nice to reduce the amount of code rustc has to process, I'd lean towards preserving the existing convention here.

[Ralith]

Thanks!

[MaikKlein]

Looks good, thanks for the PR!