Updates sampling to support resources as messages, but also to reuse the same supported message type as tool calls to enforce parity between tools and sampling.

Motivation and Context

See #503. This change improves the cohesiveness of sampling in the protocol by making sure that sampling does not lag behind tool calls in terms of what data can be handled.

How Has This Been Tested?

Breaking Changes

None from a spec perspective - if SDKs implement this as a tagged union (as the TS SDK does) and consumers assume exhaustive case handling means all types have been handled, then consumers may need to update their code to support this.

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
• 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

• Reusing the same type definition for the actual message types that tool results use is likely to be a point of contention, but I think it's important to avoid allowing sampling to become outdated. This PR does not add verbiage that actually requires them to be in sync at a specification level, so this can be revisited if cases arise in which it makes sense to only implement a message type for one feature and not the other. All this does is make parity the default decision.
• If this is merged before docs(sampling): rewrite sampling docs for MCP server builders #515, I'll backport information on resource support to that PR. If that PR is merged before this one, I'll revise the documentation changes here to respect that.