Allow subclasses to be used to customize server behavior

What I say below is (mostly) appropriate to the other types of server classes (i.e. McpSyncServer, McpStateless*), but I'm going to focus specifically on McpAsyncServer current impl for clarity.

Currently the McpAsyncServer constructors are package private...e.g.

	/**
	 * Create a new McpAsyncServer with the given transport provider and capabilities.
	 * @param mcpTransportProvider The transport layer implementation for MCP
	 * communication.
	 * @param features The MCP server supported features.
	 * @param jsonMapper The JsonMapper to use for JSON serialization/deserialization
	 */
	McpAsyncServer(McpServerTransportProvider mcpTransportProvider, McpJsonMapper jsonMapper,
			McpServerFeatures.Async features, Duration requestTimeout,
			McpUriTemplateManagerFactory uriTemplateManagerFactory, JsonSchemaValidator jsonSchemaValidator) {
		this.mcpTransportProvider = mcpTransportProvider;
		this.jsonMapper = jsonMapper;
		this.serverInfo = features.serverInfo();
		this.serverCapabilities = features.serverCapabilities().mutate().logging().build();
		this.instructions = features.instructions();
		this.tools.addAll(withStructuredOutputHandling(jsonSchemaValidator, features.tools()));
		this.resources.putAll(features.resources());
		this.resourceTemplates.putAll(features.resourceTemplates());
		this.prompts.putAll(features.prompts());
		this.completions.putAll(features.completions());
		this.uriTemplateManagerFactory = uriTemplateManagerFactory;
		this.jsonSchemaValidator = jsonSchemaValidator;

		Map<String, McpRequestHandler<?>> requestHandlers = prepareRequestHandlers();
		Map<String, McpNotificationHandler> notificationHandlers = prepareNotificationHandlers(features);

		this.protocolVersions = mcpTransportProvider.protocolVersions();

		mcpTransportProvider.setSessionFactory(transport -> {
			String sessionId = UUID.randomUUID().toString();
			return new McpServerSession(sessionId, requestTimeout, transport, this::asyncInitializeRequestHandler,
					requestHandlers, notificationHandlers, () -> this.cleanupForSession(sessionId));
		});
	}

Among other things, this means that users of the sdk cannot customize the server runtime behavior, as they are essentially forced to use not only the static factory methods, but also cannot provide custom features on construction nor customize the server initialization via the methods called in the constructor: prepareRequestHandlers, prepareNotificationHandlers, and importantly: setSessionFactory (which also means that the sessionid creation cannot be altered, nor the type of the McpServerSession.

In some servers the calling of setSessionFactory wants to be delayed, so that construction/initialization of members (feature contents, prepare method), can be separated from putting the server online by setting the session factory.

Use Case - Extensions

To implement some extensions, such as grouping and primitive update it's necessary to customize the feature set, initialization, factory setting session type and in some cases optionally override methods of McpAsyncServer (e.g. notification sending and contents) (which further need to access currently private members...e.g. list of tools, resources, primitives. With the current permissions, to do this customization would mean having to re-implement McpAsyncServer...outside of it's existing package, which seems like an unnecessary burden on sdk developers.

Also, there have been several unrelated community requests for sdk server extensibility here:

https://github.com/modelcontextprotocol/java-sdk/issues/525

I request that the McpAsyncServer (and other server root classes) be made more extensible by sdk consumers.

I understand that composition might be preferable architecturally, but to allow such composition would currently require a major refactoring and generalization of the server classes, so it seems that making members, constructors, and methods protected might be better in the short term.

Another option for implementing...that would retain binary backward compatibility...would be to introduce abstract super class(es) (for McpAsyncServer) and expose the relevant constructors, members, initialization methods in the abstract super class(es).

Beginne mit dem Lesen von McpAsyncServer, insbesondere des package-private-Konstruktors sowie der im Issue genannten Einstiegspunkte prepareRequestHandlers, prepareNotificationHandlers und setSessionFactory. Vergleiche die anderen Serverklassen auf Root-Ebene, einschließlich McpSyncServer und McpStateless*, und sieh dir die zugehörige Anfrage zur Erweiterbarkeit in Issue #525 an. Als abgeschlossen gilt die Aufgabe, wenn SDK-Nutzer Features, Initialisierung, Sitzungserstellung und Sitzungstyp sowie relevantes Serververhalten anpassen können, ohne den Server neu implementieren zu müssen.