feat(mcp): add stdio transport to mcp_client_python

[noron12234]

Problem

mcp_client_python can only reach MCP servers over SSE. on_start calls sse_client(url=...) directly, so a server that speaks stdio cannot be used at all — even though stdio is how most MCP servers are distributed and run (npx -y @modelcontextprotocol/server-filesystem /data, uvx some-mcp-server, a local script).

There is also no feedback when the extension is misconfigured: with url empty, on_start skips the whole connection block and the extension registers no tools, silently.

Change

Add a command property holding the command line of a local MCP server:

{
  "command": "npx -y @modelcontextprotocol/server-filesystem /data"
}

Transport selection moves into _create_transport:

• command set → shlex.split it and launch through stdio_client
• otherwise url set → sse_client as before
• neither → log an error and register no tools

shlex.split means ordinary shell quoting works for paths with spaces.

Both transports yield a two-element stream tuple, so ClientSession(*streams) and the existing on_stop teardown are unchanged. SSE behaviour is untouched.

The README was still the unedited template (- xxx feature); it now documents both transports and the two properties.

Verification

Against a real MCP server launched over stdio, using the same construction as _create_transport:

• shlex.split parses a quoted path correctly
• stdio_client yields 2 streams, so ClientSession(*streams) is right for this transport too
• the session initializes and list_tools() returns the server's tools

Not included

Streamable HTTP is the other transport worth having, but the SDK renamed it between major versions (streamablehttp_client in 1.x, streamable_http_client in 2.0), so it needs a version compatibility decision. Happy to follow up in a separate PR once there is a preference on how this extension should pin mcp — the current mcp>=1.2.1 has no upper bound and 2.0 is already out.