Add tee-fd capture mode and capteefd fixtures

[FazeelUsmani]

Summary

This PR implements --capture=tee-fd mode and capteefd/capteefdbinary fixtures, addressing issue #14159.

The new capture mode enables FD-level capture (including subprocess output) while simultaneously passing output through to the terminal in real-time.

closes #14159

Changes

• Add --capture=tee-fd CLI option
• Add capteefd and capteefdbinary fixtures
• Implement FDCaptureTee and FDCaptureBinaryTee classes using pipe+thread architecture
• Platform-specific implementations for Unix (using select) and Windows (using queue-based approach)
• Add comprehensive tests for the new capture mode
• Update documentation

Test Plan

• Run pytest testing/test_capture.py::TestFDCaptureTee - 11 tests pass
• Run pytest testing/test_capture.py::TestCaptureFixture::test_capteefd - fixture tests pass
• Verified no regressions in existing capture tests

[RonnyPfannschmidt]

This looks good to me

This will also need mitigation in xdist

The details that is a pain is the introduction of threads
threads
This is the first active use of threads in pytest

I do also wonder if modern syscalls like sendfile could be used for leaving most of the work to the kernel as i do have a number of unfortunate interactions with select loops

[FazeelUsmani]

Thanks!

I poked at sendfile/splice. The terminal-passthrough side could use splice on Linux to save a memcpy, but the capture side has to land in a Python bytes object for readouterr(), and the kernel calls can't do that - they only move pages between fds. So a userspace reader stays no matter what. Net effect would be a Linux-only optimisation on one half, not removing the thread.

I can consolidate the two reader threads (one per fd) into a single one for the whole MultiCapture session if that helps. Let me know.

Will open an xdist follow-up after this merges.