Client notification support

[kylestratis]

This PR expands the universe of supported server notification types that a client can handle to include all existing types defined in types.py as well as any other type deriving from ServerNotification, both unknown via a fallback handler and known via a custom handler registry.

Motivation and Context

In the current state, Python clients can only handle a few notifications sent by servers, essentially making those server-sent notifications useless. To empower client developers to handle any kind of notification servers may send them, I created this PR.

How Has This Been Tested?

• Automated testing in test_custom_notifications.py and test_notification_callbacks.py
• Runnable demo with several example scenarios

Breaking Changes

None, this approach is fully backward-compatible

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

Handling "known custom" server notifications (although I expect it to be a narrow use case right now, with private MCP registries I think this will get more popular) is done by creating a registry dictionary where the keys are the notification string literal and the values are references to the handler functions, then passing that in to a new client constructor parameter. This is given priority when routing notifications, however I am not tied to that specific ordering.

I would like eventually to do notification discovery, but I don't think the juice is worth the squeeze at the moment.

[kylestratis]

New commit does the following:

• Expands tests
• Removes handling for custom notifications. This is because the model validation does in the BaseSession class forces notifications to derive from ClientNotification or ServerNotification which are union types, while custom notifications would have to derive from Notification. I'm not sure this strict checking is found in other SDKs, as I am able to send and receive custom notifications to the MCP Inspector.
• Removes the handler for unknown notifications. The model validation makes that unnecessary, however we still need a fallback in _received_notification() to keep pyright happy. Even though the logic in BaseSession also prevents CancelledNotifications from making it to _received_notification(), pyright complains if we don't handle it, so the fallthrough case itself remains.
• Updates README and examples to reflect this change.

I'm still not hitting 100% test coverage, but I'll try to improve that in the next few days.