Restore caller compile options after configuring zlib-ng

[ProjektMing]

The zlib-ng wrapper removes /source-charset:utf-8 from the including directory to avoid conflicting with zlib-ng's /utf-8, but does not restore it. Subsequent Mono targets can fail with C4819/C2220 when compiling UTF-8 sources on Windows with code page 936 (GBK).

Save and restore the caller's directory COMPILE_OPTIONS around FetchContent_MakeAvailable(fetchzlibng). zlib-ng retains its own /utf-8, while later caller targets retain their original source charset and other compile options.

Also replace the em dash in the debugger protocol header comment with an ASCII -, so the comment does not require UTF-8 decoding.

Validation:

• MSVC Windows x64 comparison: the original wrapper reproduces C4819/C2220; the patched wrapper builds and both consumer executables produce the expected UTF-8 bytes. All 47 zlib compilation commands retain /utf-8 without /source-charset:utf-8.
• The full Mono native Windows x64 Release build and install passed for the CMake fix before the subsequent comment-only punctuation change.
• System.IO.Compression.Native-Static and System.IO.Compression.Native.Aot builds passed.
• The debugger protocol header is now entirely ASCII. The final diff confirms that only punctuation in its comment changed; git diff --check passed.

Note

This change and PR description were AI-generated with OpenAI Codex.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[ProjektMing]

@dotnet-policy-service agree

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.