[msbuild] Generate C code for the runtimeconfig properties instead of the binary runtimeconfig format (CoreCLR) #26334

Background

For our CoreCLR-based apps we bake the runtime configuration into the app and hand it directly to coreclr_initialize (we bypass hostfxr). The current pipeline is:

1. At build time, _CreateRuntimeConfiguration (in dotnet/targets/Xamarin.Shared.Sdk.targets) reads *.runtimeconfig.json (and, since [msbuild] Merge runtimeconfig.dev.json into the runtime configuration. Fixes #26330 #26332, the merged *.runtimeconfig.dev.json) and runs the shared RuntimeConfigParserTask (from dotnet/runtime) to produce a binary runtimeconfig.bin in the encoded mobile-runtimeconfig format.
2. runtimeconfig.bin is copied into the app bundle.
3. At runtime, xamarin_bridge_compute_properties (in runtime/coreclr-bridge.m) mmaps the file and decodes the length-prefixed key/value strings into char** arrays that are then passed to coreclr_initialize.

Problem

This is more complex than necessary for CoreCLR. We encode the properties into a binary blob at build time, ship the blob as a separate file in the bundle, and then mmap + decode it at startup, purely to reconstruct the two char** arrays (keys and values) that coreclr_initialize wants.

Proposal

For CoreCLR, skip the binary format entirely and instead generate a small C source file at build time that contains the property keys/values as static arrays (essentially the already-known key/value pairs baked directly into the app). That C file gets compiled into the app, and xamarin_bridge_compute_properties can use the arrays directly.

Benefits:

• No binary encoding step (we wouldn't need the RuntimeConfigParserTask for CoreCLR, nor the merge-then-parse dance).
• No extra runtimeconfig.bin file in the bundle.
• No mmap + decode logic at startup (xamarin_read_config_string / xamarin_bridge_decode_value in runtime/coreclr-bridge.m).
• The runtime configuration properties become plain compiled-in data, which is simpler to reason about and debug.

Notes / scope

• This is specific to the CoreCLR path. MonoVM consumes the blob differently (monovm_runtimeconfig_initialize with the blob path, see runtime/monovm-bridge.m), so the binary runtimeconfig.bin is still needed there. Any change should keep the MonoVM path working (or be gated to CoreCLR only).
• NativeAOT doesn't go through xamarin_bridge_vm_initialize at all.
• Follow-up from [msbuild] Merge runtimeconfig.dev.json into the runtime configuration. Fixes #26330 #26332, which added merging of *.runtimeconfig.dev.json into the configuration.