extensions/khr: Add VK_KHR_external_fence_fd wrapper

[MarijnS95]

This extension wrapper is identical to the one for VK_KHR_external_semaphore_fd introduced in #395 with 'semaphore' substitued for 'fence'.

[MarijnS95]

@MaikKlein Given your question about POSIX fd's in #395 (comment) I've been tempting to replace the types with std::os::unix::io::RawFd for clarity (also a c_int) but that requires all these extensions to be wrapped in #[cfg(unix)]. On the one hand conditional compilation might be desired (and is in some areas favoured by me) to disallow use of interfaces on a platform that couldn't possibly work at compile-time, on the other applications might (already) be doing just fine with runtime conditionals.

Either way we should probably be nice and provide the Win32 variants of these import/export functions as well.

[Ralith]

I think it's preferable to be able to build on any platform, so an application can rely on e.g. advertised extension support to select code paths without any special effort.

[MarijnS95]

@Ralith For one it's a nice way to force users to write:

let extensions = vec![
    ...
    #[cfg(unix)]
    ash::extensions::khr::ExternalFenceFd::name().as_ptr(),
    ...
];

When creating this list of desired extensions. Same when using this API, these codepaths already have to be made optional to function correctly which might as well be enforced at compile time? For example when porting a Linux/UNIX application using this API to Windows it is immediately clear that this isn't going to work, rather than having to find that out at runtime.

EDIT: I personally appreciated Rusts (and the crates around here) handholding when it comes to not exposing features that are not supported on a platform, rather than running into obscure errors at runtime. At the same time I can see that it might be desired to look at supported extensions and go from there, even though these extensions are rather specific and already need a platform-specific abstraction (Fd vs Win32 handle) anyway.

[Ralith]

It's already fairly common in Vulkan to branch between significantly different code paths depending on device capabilities, after all.

[MaikKlein]

This looks good as is it with i32 as fd. We don't have platform specific types in ash currently as well.

[MarijnS95]

@MaikKlein Thanks! Allright, let's leave it like this, the underlying type is the same anyway. Maybe someone in the future has reasons to constrain these extensions to be available on the desired (cfg(unix)) platform only, but the other extensions are anyway already exposed as-is.