feat: support logging to stderr in Jupyter Notebook environments (#156)

[dgenio]

Summary

Fixes#156 - Adds support for displaying stderr output in Jupyter Notebook environments.

Changes

• Added Jupyter/IPython detection using IPython.get_ipython()
• Implemented async stderr reader that reads stderr asynchronously (similar to stdout)
• Added IPython display integration for colored stderr output in Jupyter notebooks
• Updated process creation to pipe stderr instead of redirecting (enables async reading)
• Updated Windows process creation and fallback to support piped stderr
• Updated FallbackProcess to wrap stderr in async-compatible streams

Design Decisions

• Backward compatibility: errlog parameter is kept but behavior adapts based on environment
• Error handling: Non-critical errors are logged but don't stop execution
• Performance: Matches stdout_reader behavior (line-by-line buffering)
• Platform support: Works on both Unix and Windows (including fallback path)

Testing

• Added comprehensive tests for stderr capture, Jupyter detection, and display integration
• All existing tests pass
• Linting and type checking pass

Behavior

• In Jupyter: stderr is displayed using IPython's display system with red HTML formatting
• Outside Jupyter: stderr is printed to the provided errlog stream (defaults to sys.stderr)
• Fallback: If IPython display fails, falls back to regular print

This enables proper debugging of MCP servers in Jupyter notebook environments, addressing the issue where server crashes or command errors were invisible.

[dgenio]

Hi — I'm the author of this PR. After reviewing the current state of main, this PR is stale and won't merge cleanly:

• The src/mcp/client/stdio/__init__.py package has been restructured into a single src/mcp/client/stdio.py file, so the paths and internal structure no longer match.
• The _create_platform_compatible_process helper and process creation flow have changed.

Rather than trying to rebase this, I plan to close this PR and open a fresh one with a simpler, more focused approach — just piping stderr to an async reader and forwarding lines to errlog, without the StderrCapture class and output property. This should be easier to review and less invasive.

I'll wait for maintainer feedback on issue #156 before proceeding. Happy to close this PR now if preferred.

[maxisbey]

Thanks for your PR! Closing this in favour of #2020 as it targets the current stdio module structure with passing CI, whereas this PR is stale against the restructured codebase (as you noted).