Proposal: add IOTransport, a generalized transport over a Reader/Writer

[atomAltera]

I run an MCP server in docker container. And I use docker go library to run container and attach to it. After attach, i have io.ReadCloser for stdout and io.WriteCloser for stdin. And i need a transport which accepts io.ReadCloser and io.WriteCloser. Same as StdioTransport but with exposed reader and writers.

I think this transport may be useful for other cases as well since it is more general than StdioTransport

[findleyr]

This makes sense to me: it is generally useful, has a simple API, and must necessarily be implemented internally anyway (StdioTransport and CommandTransport are just specializations).

Once I cut v0.5.0 (today or tomorrow, I expect), I think we can merge this API addition.

Thanks.

[jba]

Is it worth getting rid of StdioTransport and using an empty IOTransport in its place?

[findleyr]

@jba I don't think so:

1. That would be a rather disruptive change, since StdioTransport is probably used throughout the user's code.
2. StdioTransport is discoverable, since stdio is used in the spec.
3. Maybe we'd want to change the behavior of stdiotransport in the future, since it is part of the spec and therefore may be subject to evolution.

On the other hand, I think we could change NewInMemoryTransports to return *IOTransports.

Thoughts?

[findleyr]

@jba if you agree, please remove the release blocker and breaking change labels.

[findleyr]

This is now done in #376.