Ability to build DXVK Native in distro environments

[smcv]

At the moment the only source code releases for DXVK are the git repository itself (which has submodules), and the autogenerated git archive from Github (which does not have the submodules). Some Linux distributions have packaging systems that can use a git repository and its submodules as source code, but others such as Debian and Fedora need to start from a tarball of some sort.

This means the git archive is missing:

• the vendored Vulkan headers (but distros can use a system copy since meson: Check for bundled Vulkan/SPIR-V headers #3836 was merged)
• the vendored SPIRV headers (but distros can use a system copy since meson: Check for bundled Vulkan/SPIR-V headers #3836 was merged)
• the vendored copy of libdisplay-info (but distros can use a system copy since [meson] Only use the libdisplay-info subproject as a fallback #3824 was merged)
• the vendored MinGW headers needed for DXVK Native

At the moment, the Debian package for DXVK has an extra tarball included in its packaging with a suitable snapshot from https://github.com/Joshua-Ashton/mingw-directx-headers, while the Fedora package copies headers from a system-wide copy of the MinGW headers at build time.

If the intention is that downstreams can rely on the submodules being present, it might be a good idea to do a meson dist at release time, and attach that as a release artifact? This is how Flatpak 1.15.x currently does its releases, for example: the official source release tarball flatpak-1.15.8.tar.xz attached to https://github.com/flatpak/flatpak/releases/tag/1.15.8 is the output of meson dist, and it contains submodules for some of the dependencies, which distros can choose to either use or bypass.

[smcv]

Alternatively, the vendored MinGW headers (which are the only dependency that can't easily be a system copy) could perhaps be managed with git subtree in preference to git submodule, similar to flatpak/flatpak#5800