ci: build Windows test leg in Debug

[abnobdoss]

What

Let the CMake CI scripts use ICEBERG_BUILD_TYPE and default to Debug, including on Windows. MSVC builds with debug info now use embedded /Z7 debug info through CMP0141 and CMAKE_MSVC_DEBUG_INFORMATION_FORMAT so Debug objects remain cacheable by sccache.

The build scripts also use the same single-config Ninja build path on every platform. Since these jobs pass -G Ninja, CMAKE_BUILD_TYPE controls the build and --config Release / ctest -C Release were not needed.

Why

Windows was the only main Test workflow leg still forcing the helper scripts through Release. After this change, the helper-script CMake test jobs default to Debug on pull requests and main; ICEBERG_BUILD_TYPE remains available if the project wants an override. Release verification and the SQL Catalog workflow's explicit Windows Release matrix entry are unchanged.

The original Windows Debug blocker in #39 was an IMPORTED_LOCATION failure from a multi-config CMake path. That specific failure no longer applies because the helper scripts now use Ninja single-config builds. The remaining Debug-only blocker was MSVC rejecting a constexpr static PartitionValues test helper: PartitionValues owns a std::vector, and MSVC Debug's checked-iterator mode (_ITERATOR_DEBUG_LEVEL != 0) makes that construction fail constant evaluation. This PR constructs the empty PartitionValues at the call site instead.

This follows the CI direction discussed in #799.

Validation

Fork validation passed:

• Test / AMD64 Windows 2025 passed in 23m48s on the pull-request run: https://github.com/abnobdoss/iceberg-cpp/actions/runs/28638474339/job/84929642907
• SQL Catalog / AMD64 Windows 2025 passed in 4m13s: https://github.com/abnobdoss/iceberg-cpp/actions/runs/28638474303/job/84929643407
• Meson / AMD64 Windows 2025 passed in 3m21s: https://github.com/abnobdoss/iceberg-cpp/actions/runs/28638474339/job/84929642897

The Windows Debug test job reported 45% sccache hits, 385 hits, 477 misses, and 0 errors. The first post-merge Apache main run will reseed Windows cache entries because the previous entries were built from Release objects.

Closes #39.

[wgtmac]

This is nice and clean! Thanks! Please resolve the conflict.

Release verification and the SQL Catalog workflow's explicit Windows Release matrix entry are unchanged.

Should we fix them altogether?

[abnobdoss]

Thank you for reviewing @wgtmac! I resolved the conflict and applied the change to SQL Catalog as well. I assume we don't want the change on the Release verification workflow, but let me know if we do want it applied there too.