Hide experimental types from external source generators using internal property pattern

[MackinnonBuck]

Problem

Experimental properties on stable protocol types (e.g. Tool.Execution, ServerCapabilities.Tasks) cause two problems for consumers who don't use those APIs:

1. Binary compatibility. The STJ source generator emits code that directly references experimental types. If an experimental type is renamed, restructured, or removed in a future SDK version, previously compiled source-generated code breaks, even if the consumer never used the experimental API.
2. Unwanted diagnostics. The source generator's references to experimental types trigger MCPEXP001 at compile time, forcing consumers to suppress a diagnostic for an API they aren't using.

Approach

Alternative to #1260. Each experimental property is marked [JsonIgnore] and delegates to an internal property marked [JsonInclude][JsonPropertyName]:

[Experimental(Experimentals.Tasks_DiagnosticId, UrlFormat = Experimentals.Tasks_Url)]
[JsonIgnore]
public ToolExecution? Execution
{
    get => ExecutionCore;
    set => ExecutionCore = value;
}

[JsonInclude]
[JsonPropertyName("execution")]
internal ToolExecution? ExecutionCore { get; set; }

This resolves both issues. Because internal members are invisible across assembly boundaries, external source generators never emit code referencing experimental types, eliminating the binary compatibility concern. And because the public property is [JsonIgnore]d, the source generator uses object rather than the experimental type, avoiding the MCPEXP001 diagnostic entirely. The only code path that serializes these properties is the SDK's own McpJsonUtilities.DefaultOptions.

Consumer experience

• Not using experimental APIs: No diagnostics, no binary coupling to experimental types. Experimental properties are still serialized on the wire through the SDK's own resolver, so protocol compatibility is maintained.
• Using experimental APIs: Suppress MCPEXP001 as usual. Serialization through McpJsonUtilities.DefaultOptions handles everything.
• Custom JsonSerializerContext + experimental APIs: Configure TypeInfoResolverChain so the SDK's resolver takes precedence for SDK types. Only needed by consumers who both use experimental APIs and define a custom serialization context.
• Stabilization: Remove [Experimental]/[JsonIgnore], add [JsonPropertyName], convert to auto-property, delete the *Core property. No consumer changes required.

Changes

• Applied the internal property pattern to all 7 experimental properties across protocol types
• Added a compile-time regression test project (ExperimentalApiRegressionTest) that builds with [JsonSerializable] references to all affected types, verifying no MCPEXP001 diagnostics are emitted
• Added a scan-based test enforcing the internal property pattern across all experimental properties
• Added serialization round-trip tests verifying behavior with consumer-defined source-generated contexts

Fixes #1255

[eiriktsarpalis]

Thanks