API: Generalize notifications for SDK server classes

I'm building an extension that uses the Java sdk that uses notifications to send 'tool add/delete/update' data to clients (e.g. when new tools are added to an MCP server at runtime).

For this extension to work, it's necessary to provide a new topic string and non-null data to the following transport-level call:

Line 510 in current McpAsyncServer

	public Mono<Void> notifyToolsListChanged() {
		return this.mcpTransportProvider.notifyClients(McpSchema.METHOD_NOTIFICATION_TOOLS_LIST_CHANGED, null);
	}

There is currently no way for the extension to add a custom param to this notification, nor to define a new value for the topic...both of which are required for the extension...e.g.:

public/protected Mono<Void> notifyToolsListChanged(String topic, Object param) {
	return this.mcpTransportProvider.notifyClients(topic, param);
}

Where my extension wishes to call via something like:

server.notifyToolsListChanged("myorg/update", myData);

In a issue #793 I suggested allowing inheritance of the McpAsyncServer class, so that the notifyToolsListChanged() could be overridden by subclasses (via public or protected constructors, constructor args, and member variables) and call the transport directly with desired arguments.

Although I still believe inheritance of core classes is sometimes reasonable for an SDK, it seems that composition is currently favored for this case. There is no way that can see for this to be done through composition currently.

This extension also needs to have some way to prevent the existing notification notifyToolsListChanged() from being sent by addTool and remove/Tool (asynchronously)...meaning that addTool/removeTool need to be customized as well.

Note that I'm interested in generalizing this update extension to other primitives...e.g. resources and prompts...plus others...so the same extension access for server-side dynamic updates. Ultimately it's not just for tools but I'm starting with tools.

On the McpAsyncClient, conversely, there are notification handlers that can be passed into the client on construction, allowing it to receive custom topics with params.

Clearly there are multiple ways to fix this in the SDK. One suggestion: Consider defining a public AbstractAsyncServer superclass, and moving protected members, constructors, and generalized methods into that super class. This is the one way with inheritance that I'm aware of that allows generalization and will not break binary compatibility for the current McpAsyncServer API consumers (e.g. by renaming public methods).

With that said, I'm open to composition rather than inheritance as a solution (as long as it supports what this update extension needs), but afaict will likely require larger refactoring and perhaps API changes at this point.

Empieza en McpAsyncServer, especialmente en notifyToolsListChanged() alrededor de la línea 510, y sigue cómo addTool y removeTool activan las notificaciones. Compara esto con los manejadores de notificaciones de McpAsyncClient y revisa el issue #793. La solución terminada debería proporcionar una forma compatible para que las extensiones del servidor envíen temas personalizados con datos y controlen las notificaciones automáticas de herramientas existentes, dejando margen para recursos y prompts.