This should be done explicitly.

This just disables the vulkan headers from defining any symbols
like vkCmdPipelineBarrier2(). Instead, all functions must be loaded
via the loader and used as function pointers as vk->CmdPipelineBarrier2.

Mostly just forces developers to write correct code, as using the
symbols can be undesirable in case API users define their own
function wrappers via the loader API.

Needed for both encoding and decoding.

Finally, a way to directly identify a Vulkan device from a DRM device!

VAAPI is sadly on the way of becoming multiplaform.

The hack was added to enable exporting of vulkan images to DRM.
On Intel hardware, specifically for DRM images, all planes must be
allocated next to each other, due to hardware limitation, so the hack
used a single large allocation and suballocated all planes from it.

By natively supporting multiplane images, the driver is what decides
the layout, so exporting just works.

It's a hack because it conflicted heavily with image allocation, and
with the whole ecosystem in general, before multiplane images were
supported, which just made it redundant.

This is also the commit which broke the hwcontext hardest and prompted
the entire rewrite in the first place.

This just bumps the required loader library version (libvulkan).
All device-related features, such as video decoding, atomics, etc.
are still optional and the code deals with their loss on a local level
(e.g. the decoder or filter checks for the features it needs, not
the hwcontext).

Bumping the required version essentially packs all maintenance
extensions which correct the spec rather than requiring to enable
them individually.