dzn: port code to plain c

When we started making Dozen, we decided on using C++ for a few reasons:

1. The D3D12 API wasn't available as a C API at the time
2. The DXCompiler API (which we need parts of for shader-validation) isn't available as a C API either.
3. Even when there's a C API, the COM C APIs are very verbose to use.

However, after landing this code upstream, we've realized that this has led to more friction than we want:

• To support including modern C header files (i.e the vulkan runtime etc support code in mesa), we need support for designated initializers, which is a C++20 feature.
  • Meson's C++20 support is very new (requires Meson 60.0 or later), and isn't supported in the Meson version used in all distros we want to support
  • Dozen can't currently be built on Visual Studio 2019 without modifications, because Visual Studio 2019 predates C++20 support. Visual Studio 2022 works fine, but is a fairly new thing that less people have installed.
• C and C++ disagree on how to construct objects (e.g foo = (my_type) { ... } vs foo = my_type { ... })
• C and C++ disagree on how to zero-initialize arrays and objects (e.g int my_array[] = { 0 }; vs int my_array[] = {};)

I'm sure there's more issues that we haven't encountered yet or even just forgot about as well.

Over time, I expect this friction to get worse and worse, and annoy other developers more and more. And as the only Vulkan driver using C++ for the actual driver-bits only compiles on Windows at the moment, it's kind of hard for non-Windows people to add shared Vulkan support-code without risking breaking things.

The good news is that since we made the decision on C++, things have changed:

1. The D3D12 API is now available as a C API!
2. We have wrapped up the DXCompiler API in a C API for code-reuse (see !15751 (merged))

So, the only reason to choose C++ that still stands is that calling COM C APIs is still pretty verbose. But in light of the friction issues above, I think it's worth it. So here's an MR that ports the entirety of Dozen from C++ to C. I'm sure we can clean up the verbosity issue a bit by using some bespoke macros instead of COBJMACROS if we really want to, but I've left that as an exercise for later.

Also, there's some patches that are split up for rebasing reasons, and meant to be squashed before merging. The reason is that if I both rename files and make changes in the same commit, rebasing the result is going to become a lot harder. But I think it's also easier to review this way. The problem is just that the intermediate results doesn't compile, so bisecting across them will be annoying.