Add IOTransport for separate reader/writer

[atomAltera]

This commit adds ability to create a mcp.Transport with specific io.ReadCloser and io.WriteCloser.
Ii is needed when you need create an mcp.Client for mcp.Server launched in separate process and you need to communicate with it with it's own stdin/stdout.

[findleyr]

We have a CommandTransport for communicating with a server started via an exec.Cmd. What's the use case for separating the transport from the command lifecycle?

In other words: why do you need to start the process separately from connecting the server?

[atomAltera]

I have the following case: I run a command in a Docker container using the Docker Go package. Its ContainerAttach call returns a bufio.Reader for reading from stdout/stderr and a net.Conn for writing to stdin. Since I couldn’t find a suitable transport implementation, I decided to add a new one.

The reason I launch MCP servers in a Docker container is that my environment already uses Docker, and I prefer using ready-made Docker images instead of installing additional tools like Node.js or Python.

[findleyr]

Understood, I support this change.

Could you please file a proposal issue describing your use case (e.g. "Proposal: add IOTransport, a generalized transport over a Reader/Writer").

We need to keep the proposal open for a week for feedback, but can still merge this CL as long as it's not released.

[findleyr]

Let's just make these exported fields, so that the transport is extensible, and remove NewIOTransport.

See also #286