Due to the large amount of variants, and the different kind of values
connected to each variant (hash, extension name) being scattered
across the various `impl` blocks, the file became rather convoluted.
While I don't generally like the indirection of macros or meta
programming, it's not that bad with Rust, thanks to Rust Analyzer being
able to attach diagnostics to the source inside the macro definition,
and the ability to generate the macro's output for validation.
Therefore, the new macro allows putting all data used for this enum
definition into a single block.
I ended up wrapping the raw data in a `BundleFile` twice.
I also made '--compile' the default, as it should be much less often
that raw data needs to be inserted. Even files that are essentially raw
binary blobs, like `.wwise_event`, still have some custom fields that
need to be accounted for.
Can come in handy when other people report problems and show the error
message or full log, but not the command line.
Setting that span to `level = "error"` ensures that it won't be disabled
by level filters.
The second compression method found in the game's code seems to be Zlib,
but it doesn't seem to be used in the game files. What does get used is
a compression type of `0`, which appears to be uncompressed data.
For DDS formats, all the ones that are currently used by in the game
files can be emitted as is. Though for some of them, other tools might
not be able to display them.
Decompiling the game binary shows a rather elaborate algorithm to load
DDS images from binary. Though comparing it to Microsoft's documentation
on DDS, most of it seems to be pretty standard handling.
However, we don't actually need all of it. The part about calculating
pitch and reading blocks only accesses a subset of the `ImageFormat`
struct, so we can strip our implementation to just that.
