test: add compress-to-zip tests

[Fedr]

What

Adds source/MRTest/MRZipCompressTests.cpp with two GoogleTest cases that exercise MeshLib's zip write path (compressZip → libzip → zlib deflate) on deliberately different workloads. Both are designed as realistic end-to-end benchmarks — easy to scale up for backend comparisons, small by default so they don't bloat the everyday MRTest run.

MRMesh.CompressSphereToZip

One large binary file.

1. Creates a sphere via makeSphere({ radius=1, numMeshVertices=N }).
2. Saves it as sphere.mrmesh in a UniqueTemporaryFolder.
3. Compresses the folder into sphere.zip in a second temp folder (so the zip isn't inside the folder being compressed).
4. Asserts both files exist and are non-empty; logs their sizes via spdlog::info.

Default N = 1000 vertices for the everyday run. Source comment documents bumping to N = 100_000 for benchmarking (produces a ~12 MB .mrmesh — closer to realistic scene data).

MRMesh.CompressManySmallFilesToZip

Many small mixed-type files. Pairs with the sphere test to compare one-large-file vs many-small-files on the same compressZip call.

1. Writes numBinaryFiles .bin files of deterministic pseudo-random bytes (LCG-seeded per index; near-incompressible, representative of mesh coordinate floats / compressed-texture blobs).
2. Writes numJsonFiles .json files of deterministic JSON-ish text padded to exactly bytesPerFile bytes (highly compressible, representative of scene metadata and logs).
3. Compresses the folder into many.zip; asserts existence; logs input and output sizes.

Default (20 + 20) files × 6000 bytes = 240 KB for everyday runs. Source comment documents bumping to (200 + 200) × 60_000 = ~24 MB for benchmarking, matching the scaled-up sphere size.

Why two tests

libzip compresses each entry independently, so per-entry overhead (local file header, CRC32 pass, separate deflate session) is a different share of compressZip's time depending on whether the archive has one big file or many small ones. Having both tests in the same run surfaces that overhead clearly and lets compression-backend changes (e.g. PR #5932's zlib → zlib-ng overlay) be evaluated on both ends of the spectrum.

Measured compressZip time on bumped-up sizes (for reference)

Running the tests with the benchmark-size constants against MeshLib's Windows + Linux-vcpkg matrix, stock zlib vs zlib-ng (from PR #5932):

Matrix leg	Sphere (12 MB single file)	Many files (400 × 60 KB)
linux-vcpkg Release x64 Clang 20	−54%	−62%
linux-vcpkg Release arm64 Clang 20	−45%	−64%
linux-vcpkg Debug x64 GCC 11	−36%	−62%
linux-vcpkg Debug arm64 GCC 11	−45%	−63%
windows msvc-2022 Release CMake	−48%	−56%
windows msvc-2022 Debug MSBuild	−24%	−22%

(compressZip wall time as reported by MRTest's "Main thread time tree" dump at the end of the run.)

Many-small-files consistently sees a slightly larger speedup than one-large-file on Release; Debug is ~22-24% on both workloads.

No CMake / build changes

source/MRTest/CMakeLists.txt globs *.cpp, so the new file is picked up automatically. All dependencies (MRMesh, MRMeshSave, MRMakeSphereMesh, MRZip, MRUniqueTemporaryFolder, MRSpdlog) are already linked into MRTest.

Everyday vs benchmark runs

Defaults keep MRTest wall time short; scaling the file-count / vertex-count constants up turns either test into a compression benchmark without other changes. Both logged sizes via spdlog::info flow into the Unit Tests step output; the "Main thread time tree" dump at the end of MRTest reports per-call compressZip wall time in seconds.