Enable complete Tasks extension conformance coverage

[PranavSenthilnathan]

Summary

• add Tasks-owned per-call execution modes for synchronous, optional, and required task execution
• allow WithTasks callers to select execution behavior from the tool request without introducing Tasks dependencies in Core or ASP.NET Core
• enable all ten SEP-2663 Tasks extension conformance scenarios
• cover mode selection, capability enforcement, legacy protocol behavior, and invalid configuration

Validation

• dotnet build (0 warnings, 0 errors)
• all ten Tasks conformance scenarios on .NET 8, .NET 9, and .NET 10 using @modelcontextprotocol/conformance@0.2.0-alpha.9
• full Core tests on .NET 8, .NET 9, .NET 10, and .NET Framework 4.7.2
• full ASP.NET Core tests on .NET 8, .NET 9, and .NET 10
• analyzer and experimental API regression tests

[jeffhandley]

Do I understand correctly?

1. This return value is never consumed and it's immaterial
2. "required-tool" gets recognized by the store, treating the tool as required from the client
3. When the client doesn't have the tool, the 2 tests above assert we throw expectedly
4. When the client does have the tool, we simply assert that it gets registered as a task
5. Not much value in asserting the "required" result since that's the same coverage as the "sync" assert?

If that's all correctly, I suggest we go ahead and assert the "required" result anyway, to close this loop for illustration/documentation. Can't hurt to assert the result too, just in case something in the required tool mechanism ever interfered with the result.

[jeffhandley]

Just one minor question/suggestion.

[tarekgh]

Modulo @jeffhandley comment, LGTM!