Adds support for notifications/progress

[alainakafkes]

Motivation and Context

this PR adds support for progress notifications (aka notifications/progress) from the 2025-03-26 spec.

How Has This Been Tested?

i validated this change locally within a private codebase that uses this swift package. i updated that codebase to point to this feature branch via

.package(url: "https://github.com/alainakafkes/swift-sdk.git", branch: "progress")

and confirmed that i received progress notifications when i attached a progressToken to a callTool request.

the spec mandates that both clients and servers should be capable of subscribing to progress notifications, but i only validated the client case. however, i believe the logic i wrote should work for servers subscribing to clients as well. if reviewers know of any sample projects in which i might validate this behavior, please let me know!

i also wrote some unit tests for the new ProgressNotification type following the existing pattern set by the ResourceUpdatedNotification unit tests.

Breaking Changes

there shouldn't be any! i followed @stallent's first suggestion in #82, which avoids breaking changes.

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

i roughly adhered to the pattern set by ResourceUpdatedNotification, which has no special error handling. however, please let me know if there's something i missed, and i'd be happy to update this PR!

Additional context

there are multiple ways to support progress notifications within this repository, most of which @stallent outlines in #82. i'll summarize them here briefly, and explain why i chose this particular design:

1. require that callers must pass a progressToken in _meta arguments when invoking a method (e.g., callTool). sender does not deliver progress directly; instead, the caller must subscribe to the notifications/progress stream for notifications (messages) with the progressToken passed into the method.
2. add an optional progress closure to all methods that support progress tracking. sender invokes this closure when it wishes to notify caller of progress.
3. modify the return types of all methods that support progress tracking to include an AsyncStream for progress notifications. callers can optionally process the progress updates that come through this stream.

i did not consider option 2 because it doesn't feel like a modern iOS design pattern, and chose option 1 over option 3 because i like that it should work for all eligible methods with a minimal code footprint. the downside of option 1, however, is that the SDK does not make subscribing to progress notifications very obvious 😅 maintainers and community users, let me know what you think!