Introduce acceptance helpers to ElicitResult and client capability checks on IMcpServer

[dogukandemir]

This PR has following additions on IMcpServer and ElicitResult.

• IMcpServer.ClientSupportsElicitation()
• IMcpServer.ClientSupportsSampling()
• IMcpServer.ClientSupportsRoots()
• ElicitResult.IsAccepted
• ElicitResult.IsDeclined
• ElicitResult.IsCancelled

Motivation and Context

Motivation is to make code more readable and less error-prone than direct string comparisons.

How Has This Been Tested?

All newly added functionality tested in unit tests.

Breaking Changes

There is no breaking change.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
  • Note: Since this change is not related with protocol itself, I haven't read it all.
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[halter73]

I'm personally a fan of IsAccepted/IsDeclined/IsCanceled so you don't have to carefully read the doc comments or look up the spec to see what the possible values are. An alternative might be an enum, but this is certainly more flexible.

If we add SupportsElicitation, I think we should add SupportsSampling and SupportsRoots for completeness.

[dogukandemir]

I'm personally a fan of IsAccepted/IsDeclined/IsCanceled so you don't have to carefully read the doc comments or look up the spec to see what the possible values are. An alternative might be an enum, but this is certainly more flexible.

If we add SupportsElicitation, I think we should add SupportsSampling and SupportsRoots for completeness.

@halter73 Checking support of sampling and roots extension methods are added with ClientSupportsSampling and ClientSupportsRoots method names. Client prefix is suggested by @PederHP and it totally makes sense in this context.

[stephentoub]

These would be better as properties rather than as methods. Should we start thinking about using C# 14?

[dogukandemir]

I assume you're referring to extension members, right? if that's the case, I suggest we merge this PR as-is and then I can work on a follow up PR to convert all extension methods in whole solution to extension members for consistency.

[dogukandemir]

@stephentoub is it ok to resolve this conversation and proceed with what I suggested?

[eiriktsarpalis]

I would say let's remove these methods for now and reconsider once C# 14 is generally available. There's also this ongoing PR that proposes to convert IMcpClient et al to abstract interfaces so extensions might not even be necessary.