Apply StormLib big-endian build fixes to the vendored copy

[Scottcjn]

Fixes #518.

The bundled StormLib is missing the big-endian fixes from upstream StormLib commit d1b47ab, so the build fails on big-endian platforms such as macppc (the build log referenced in #518).

Why it breaks the build

On big-endian the BSWAP_ARRAY* macros expand to real calls (they are no-ops on little-endian, which is why CI never caught it). Two of them reference symbols that do not exist in scope:

• SFilePatchArchives.cpp: pPatchHeader instead of &PatchHeader
• SFileAttributes.cpp: cbCRC32Size / cbFileTimeSize instead of cbArraySize

The patch also fixes two correctness issues in the same upstream commit: the version checks in ConvertTMPQHeader (== to >=, so higher MPQ format versions still get the lower-version byte swaps) and the Platform/Reserved field order in the big-endian branch of TMPQHash.

Verification

I forced the big-endian path (-D__BIG_ENDIAN__) with a big-endian MIPS cross compiler. The three affected files fail to compile before this change ('pPatchHeader' was not declared, 'cbCRC32Size' was not declared, 'cbFileTimeSize' was not declared) and compile cleanly after. This is a straight application of the upstream StormLib fix to the vendored copy.

[Scottcjn]

Confirmed on real PowerPC hardware. I reproduced and fixed this on a Power Mac G5 (Darwin/PowerPC, big-endian) which is the same macppc family as the build log in #518. The compiler auto-defines __BIG_ENDIAN__ there, so StormLib's big-endian path is active with no forcing.

Before the patch (native G5, gcc 10.5):

SFilePatchArchives.cpp:483: error: 'pPatchHeader' was not declared in this scope
SFileAttributes.cpp:183:   error: 'cbCRC32Size' was not declared in this scope

After the patch, all three affected files compile clean. So this is verified end to end on actual big-endian PowerPC silicon, not only by forcing the BE macros under cross-compilation.

[Jarod42]

Wonder if we can use submodule instead of embedding source here...

[Scottcjn]

Good call, a submodule would be cleaner than the embedded copy. master already vendors StormLib via the dependencies submodule, so this would line this branch up with that. For this PR the embedded copy is what breaks the big-endian build today, so the four line fix unblocks macppc right now. Happy to leave it as the minimal embedded-source fix, or rework it as a StormLib submodule bump pointing at a commit that already includes the upstream big-endian fix (d1b47ab), whichever direction you prefer to merge.

[Scottcjn]

Agreed, and it would fix the root cause more cleanly than carrying a patch. The big-endian fixes in this PR are already upstream in StormLib (ladislav-zezula/StormLib commit d1b47ab), so if the embedded StormLib/ directory here became a git submodule pointing at a recent upstream commit, you would pick up this fix (and future ones) for free with nothing to maintain in-tree.

To be precise about the current layout: StormLib/ is embedded directly in the tree right now, and the only submodule is third-party (Wargus/dependencies). So a couple of clean options:

• Replace the embedded StormLib/ directory with a submodule at an upstream StormLib commit that already includes d1b47ab.
• Or fold StormLib into the existing third-party (Wargus/dependencies) submodule, the way the other dependencies are handled.

I am happy to rework this PR into whichever of those you prefer. If you would rather keep the in-tree copy for now, the four line fix here already unblocks the big-endian build, and the submodule migration can land as a separate change. Just let me know the direction.

[Jarod42]

Merged for now to fix the issue.

Wargus/dependencies submodule is also a inline copy of other repos, so not a clean option for me :-( .
so, as you said:

Replace the embedded StormLib/ directory with a submodule at an upstream StormLib commit that already includes d1b47ab.

seems the cleaner option for me.

So use the official repo directly.
If custom changes are needed, we might still create a clone repo Wargus/StormLib.