Add opt-out for Streamable HTTP standalone GET stream

[jstar0]

Fixes #1637.

Summary

Adds HttpClientTransportOptions.EnableStandaloneGetStream (a bool that defaults to true) so Streamable HTTP clients can skip the standalone GET SSE stream when they do not need unsolicited server-to-client messages.

Default behavior is unchanged: the transport opens the standalone GET SSE stream after initialization. Set the option to false to skip it -- the transport no longer starts ReceiveUnsolicitedMessagesAsync() after initialize or when resuming a known session, but direct and streaming responses to client POST requests still work.

Changes

• Added HttpClientTransportOptions.EnableStandaloneGetStream (default true).
• Routed Streamable HTTP standalone GET startup through the new option for the initialize and known-session paths.
• Preserved structured HTTP completion details when AutoDetect adopts Streamable HTTP without opening a standalone GET stream.
• Added regression coverage for initialize, known-session, POST SSE response behavior, and AutoDetect disposal.
• Documented the option in the transport and session docs.

Why

Some clients run with constrained HttpClient connection pools. If a server holds the standalone GET stream open, later POSTs can queue behind that long-lived request and initialization can time out. Setting EnableStandaloneGetStream to false gives those clients a narrow opt-out without changing default behavior for clients that rely on unsolicited notifications.

Verification

dotnet test tests/ModelContextProtocol.Tests/ModelContextProtocol.Tests.csproj --framework net10.0 --filter FullyQualifiedName~HttpClientTransportTests --no-restore
dotnet test tests/ModelContextProtocol.Tests/ModelContextProtocol.Tests.csproj --framework net10.0 --no-restore
dotnet build src/ModelContextProtocol.Core/ModelContextProtocol.Core.csproj --no-restore

[jstar0]

The two failing Linux jobs are in unrelated OAuth integration tests: Debug failed in CanAuthenticate_WithAuthorizationServerPathFallbacks, while Release failed in AuthorizationFlow_AllowsOneStepUpEvenWhenChallengeAddsNoNewScope. This PR does not touch the OAuth implementation or tests, macOS and Windows passed, and recent main runs have shown failures in the same OAuth test family.

I do not have permission to rerun the upstream workflow. Could a maintainer rerun the failed jobs? I will leave the transport patch unchanged unless a changed-surface test fails.