Proposal: support for sending `tools/list_changed` notifications manually

Is your feature request related to a problem? Please describe.
At the moment in this library it seems to only be possible to send a tools/list_changed notifications when one of two events are triggered: AddTools and RemoveTools. In the GitHub MCP Server we would like to extend this so that these notifications can be sent when other conditions occur such as a mismatch in the version of the MCP server in a session and the client. At this point in time, this does not seem to be possible.

Describe the solution you'd like
For context, we create a new mcp.Server instance per request, since each user may have different tools depending on factors such as their license, the client the token was minted for, if they are a staff user, or if they have a feature toggled on. Because we construct a server for each request, we never add new tools to a server, they are simply there before the server is started.

That being said, we do need a way of notifying clients that new tools are available when they are released. We're looking at doing this via this notification when the available tools differ from what is stored in their session (which is handled outside the scope of the MCP server's internal sessions.)

Describe alternatives you've considered

1. Forcing tool registration changes: We considered artificially adding/removing a dummy tool to trigger the notification, but this is hacky and pollutes the tool list unnecessarily.

2. We've also looked at intercepting requests and return a 400, invalidating a MCP session and theoretically having the client reinitialise their connection thereby getting a new tool list. In practice this is not well supported, while this works in VSCode for example, in Claude Code it results in a persistent broken connections until the agent runtime is restarted.

cc @omgitsads

Start by tracing how AddTools and RemoveTools trigger tools/list_changed notifications in the Go SDK. Identify the server notification path and determine how a caller could request the same notification when tools were registered before the server started. Done means callers can manually send the notification without adding or removing a dummy tool, with behavior covered by the relevant tests.