feat!: add SEP-2322 MRTR model types

[DaleSeo]

Motivation and Context

SEP-2322 introduces a stateless pattern where a server responds to tools/call, prompts/get, or resources/read with an InputRequiredResult (carrying inputRequests and/or requestState), and the client retries with inputResponses. This replaces the previous URLElicitationRequiredError (-32042) approach. Relates to #871.

The draft spec also adds a resultType discriminator to the base Result type (required in the JSON schema). This PR adds result_type: ResultType to all server result types that require it per the schema: CallToolResult, GetPromptResult, ReadResourceResult, CompleteResult, and the four paginated results (ListToolsResult, ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult). resultType is always serialized (matching the Python SDK's approach per the spec's MUST). Types that don't have resultType in the schema (InitializeResult, task results, client results) are unchanged.

This PR adds only the model/serde layer. Behavior wiring (server emit, client retry, version gating) is planned for a follow-up.

How Has This Been Tested?

13 unit tests in model/mrtr.rs covering serde round-trips against spec example JSON, rejection of missing/wrong resultType, unknown extension value preservation, and constructor behavior. Full suite passes with 0 failures.

cargo test -p rmcp --lib mrtr::tests
cargo test -p rmcp

Breaking Changes

All server result types gain a result_type: ResultType field. The field defaults to "complete" and is always serialized, so responses now include "resultType": "complete". Struct literals that construct result types directly (not through constructors or ..Default::default()) will need the new field added. The #[tool_handler] and #[prompt_handler] proc macros have been updated. The SemVer check flags adding InputRequiredResult to the exhaustive ServerResult union.

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