GLideNHQ: zstd compression for texture cache

[GhostlyDark]

This adds zstd compression support. Closes #2913.

Currently it's simply using the zlibWrapper to support both zlib and zstd compression streams. For testing purposes, the compression level is cranked up to level 9.

Initial size comparisons (HTS cache) for OoT Reloaded texture pack:
uncompressed: 28.5 GB (30.694.669.834 bytes)
zlib-level1: 8.28 GB (8 897 605 579 bytes)
zstd-level1: 8.69 GB (9 334 399 841 bytes)
zstd-level9: 6.80 GB (7 307 463 076 bytes)

Higher zstd compression levels generally do not affect decompression speeds at all, which is one of the main benefits of zstandard. Do note that level9 in this case is just the level9 compression level of zlib translated by the wrapper, not the actual zstd compression level (which ranges up to 22).

An HTS file using zstd outperforms any zlib compressed one, reducing stutter quite noticeably. I did however notice that uncompressed cache files still perform better. The zlibWrapper causes some overhead, so the wrapper itself introduces a performance degradation that otherwise wouldn't be there (unknown by how much exactly).

Numbers from the zstd repo, which I believe to be somewhat accurate:

[gonetz]

@GhostlyDark I totally agree with your idea to add support of zstd compression. I briefly checked the modification you made in GLideN64 sources, they look correct. I even think that we can left UI unchanged and silently use zstd instead of zlib if it is supported. The only thing which concerns me in this PR is include of zstd sources to GLideN64. IMO, it is overkill. Did you make it for draft only? I think, this library should be used the same way as we use other external libraries: freetype, libpng, zlib.
That is, add windows lib files for windows build and use system zstd on other platforms. If zstd is not available on a platform, fallback to zlib.

[GhostlyDark]

I even think that we can left UI unchanged and silently use zstd instead of zlib if it is supported.

Then we'll go this route. The zlibWrapper won't use zstd unless ZWRAP_USE_ZSTD is set to 1, which can be controlled during compile time.

The only thing which concerns me in this PR is include of zstd sources to GLideN64. IMO, it is overkill. Did you make it for draft only? I think, this library should be used the same way as we use other external libraries: freetype, libpng, zlib.
That is, add windows lib files for windows build and use system zstd on other platforms.

I agree to this. I opened this as a draft, hoping for some input on how the implementation should look like. I think it's also part of the reason why GitHub actions are failing. I'll definitely adjust this.

If zstd is not available on a platform, fallback to zlib.

In such a case, the zlibWrapper can't be used and it should then fall back to using zlib.h with the compression level for texture caches set to 1.

[GhostlyDark]

@gonetz I tried a couple of different things, but I keep struggling with getting Visual Studio to work correctly. It either doesn't compile or if it does, ZSTD is somehow not included in the GLideN64 binary - the latter being the case for the current Windows GitHub Action builds.

The zlibWrapper requires ZSTD to be included in order to work. I found that using FIND_PACKAGE may not work in certain cases, which happens on Ubuntu 22.04 for instance when using -DUSE_SYSTEM_LIBS=ON. The system can't find the package, even if the correct one (libzstd-dev) is installed on the system. The ZSTD repository offers the creation of a single file library, which is something I implemented with the last commit that I pushed. While this does include the entire source code in a sense, it is condensed into a single file and works around any package related issues.

[GhostlyDark]

It's possible that QtZlib and zlibWrapper conflict as they both use Z_PREFIX. In case that's true, it's due to the -qt-zlib parameter used to compile the static Qt builds that GLideN64 is linking to. I do require static Qt builds with -system-zlib passed to test this out however, which unforunately I am unable to compile myself:
LINK : fatal error LNK1181: cannot open input file 'project.obj'

[GhostlyDark]

@gonetz
As it turns out, Qt5Core (which contains QtZlib) does conflict with the zlibWrapper because of the z_ prefixed symbols. Is GlideNUI even using QtZlib in the first place? Recompiling Qt with -system-zlib should hopefully fix this annoyance and make this PR fully functional. To confirm things, I manually edited the Qt5Core.lib by replacing the strings of the corresponding symbols from z_ to __. The Qt builds of the GLideN64 plugin binary are going to be bigger if compiled against the modified lib files (otherwise zstd is sort of stripped away, thus the binary file is smaller), which indiciates whether or not the build works as expected.

Qt5Corex86.zip
Qt5Corex64.zip

That aside, there's a few things I want to discuss:

• Are you fine with including the ZSTD source as a single file or do you still want me to use find_package and bundle ZSTD static lib files for MSVC (around 20 MB total)? I'll change this according to whatever your answer will be.
• I did bump the compression level to 9, but ZSTD does compress much faster with level 1 (and thus also much faster than zlib compression level 1). Should we simply use level 1 for speed reasons?
• I updated the zlib headers and .lib files for MSVC. Technically this is not required for this PR to work.
• zstd has been added as a dependency for the GitHub Actions worker to install. I'm not sure if this is actually needed.