[Server] Refactor protocol pipeline to separate request and notification handling

[CodeWithKyrian]

This PR introduces a new Protocol layer, reshapes message parsing, and redefines how custom handlers plug into the server. The Protocol exposes handleRequest, handleNotification, and a placeholder handleResponse, along with sendRequest, sendResponse, and sendNotification. Only response sending is wired for now, but the other direction-facing methods lay the foundation for server-initiated messaging.

Motivation and Context

• The old JsonRpcHandler/MethodHandlerInterface blended request and notification semantics, making it impossible to enforce the JSON‑RPC contract (requests must yield Response|Error, notifications return nothing).
• Preparing for server‑initiated messaging (sampling, logging, custom notifications) required a bidirectional protocol layer that can send as well as receive.
• The existing message factory only understood requests/notifications; it could not parse responses or errors, blocking any future server‑initiated flows.
• To keep responsibilities clear, the server should manage the transport lifecycle (initialize → connect → listen → close) while the protocol owns all transport callbacks (onMessage, onSessionEnd, and any future hooks) and output routing.

What’s Changed

• Renamed JsonRpcHandler to Protocol and made it the transport-facing façade that registers callbacks, parses all JSON‑RPC message types, dispatches request/notification handlers, and emits responses.
• Shifted Server::run() into a small lifecycle orchestrator: it initializes the transport, connects the protocol, runs listen(), and guarantees close(). No more callback wiring in Server.
• Replaced the coarse MethodHandlerInterface with RequestHandlerInterface and NotificationHandlerInterface, enforcing that requests always return Response|Error and notifications remain fire-and-forget.
• Refactored MessageFactory to emit typed Request, Notification, Response, and Error objects (or InvalidInputMessageException), laying the groundwork for bidirectional messaging.
• Added new builder hooks, addRequestHandler(s) and addNotificationHandler(s), and updated docs, examples, and tests to use the new abstractions.

Breaking Changes

• Builder::addMethodHandler(s) and MethodHandlerInterface have been removed.
• Use addRequestHandler(s)/RequestHandlerInterface for JSON‑RPC requests and
  addNotificationHandler(s)/NotificationHandlerInterface for notifications.

[chr-hertel]

a bit funny to see that because having notification and request handlers separate was exactly how i started:
https://github.com/php-llm/mcp-sdk/tree/5bfd6bf757da756501b73242e11cf386de0c6ddc/src/Server

i treated both similar, that why i brought it up one level and unified. buuut, the context here is different - so i'm in for doing it 👍

[chr-hertel]

extra mile 😎 👍