Fix UTF-8 string marshaling in NativeAOT bridge

[EFrostBlade]

Summary

• Decode all native char* inputs as UTF-8 in the NativeAOT bridge.
• Return decompiled source, script metadata, file lists, and progress text as null-terminated UTF-8 while preserving the existing AllocHGlobal/FreeHGlobal ownership contract.
• Document the UTF-8 contract in the public C header.

Problem

The Godot C++ wrapper passes strings with String::utf8() / String.utf8() and reads returned strings with String::utf8(), but the NativeAOT layer used Marshal.PtrToStringAnsi and Marshal.StringToHGlobalAnsi.

On Windows, an assembly located under a non-ASCII path was decoded incorrectly and reported as Not a valid .NET assembly?. Moving the same assembly and dependencies to an ASCII-only path made it load, while strings returned in the other direction produced Unicode parsing errors.

Compatibility

ASCII behavior is unchanged. The repository's C++ caller already uses UTF-8, and allocation/freeing remains ABI-compatible. A third-party caller that intentionally passed a legacy Windows code-page string would need to switch to UTF-8; the header now makes the intended contract explicit.

Validation

• dotnet build GodotMonoDecompNativeAOT.csproj -c Release -r win-x64: succeeds.
• UTF-8 inbound array and outbound allocation round-trip tests include Chinese paths and non-ASCII symbols.
• Full Actions matrix passes, including Windows Editor, Windows Template Release, Windows export, and Windows test: https://github.com/EFrostBlade/gdsdecomp/actions/runs/29596484774
• The resulting Windows standalone build recovered the project using its original non-ASCII PCK and assembly paths, with zero assembly-load errors and zero Unicode parsing errors.

[nikitalita]

This is a very obviously LLM generated PR, but the fixes are obvious. Next time, just take the time to write the description yourself.

[nikitalita]

thanks!