Add streaming support

[thelovekesh]

Fixes: #1056

Pull Request Type

• I have checked there is no other PR open for the same change.

This is a:

• Bug fix
• New feature
• Documentation improvement
• Code quality improvement

Context

Adds opt-in support for reading HTTP response bodies incrementally as they arrive instead of buffering the entire response before returning. This provides the low-level primitive needed for streaming consumers while preserving the existing behavior for all non-streaming requests.

Detailed Description

• Adds an opt-in streaming mode for Requests responses.
• Introduces a readable response body that can be consumed incrementally while the transfer is still in progress.
• Updates the cURL and fsockopen transports to expose response data without eagerly buffering the complete body when streaming is enabled.
• Preserves the existing buffered behavior by default, so there are no changes for existing callers.
• Lays the foundation for WP_Http to expose streaming responses and for higher-level consumers, such as the AI client SDK, to process streamed HTTP responses using a pull-based API.

Quality assurance

• This change does NOT contain a breaking change (fix or feature that would cause existing functionality to change).
• I have commented my code, particularly in hard-to-understand areas.
• I have added unit tests to accompany this PR.
• The (new/existing) tests cover this PR 100%.
• I have (manually) tested this code to the best of my abilities.
• My code follows the style guidelines of this project.

Documentation

For new features:

• I have added a code example showing how to use this feature to the examples directory.
• I have added documentation about this feature to the docs directory.
  If the documentation is in a new markdown file, I have added a link to this new file to the Docs folder README.md file.

[jrfnl]

@thelovekesh Out of curiosity: could this feature be created as an add-on package to Requests instead of having to go into te main package ?

[thelovekesh]

@jrfnl We need this in core because it vendors this package directly, so an add-on can't access it. Also, the transport classes are final, so an add-on can't extend them and would need to fork them. The part that can live outside already does: the PSR-7/PSR-18 adaptation stays in the existing adapter package.

[jrfnl]

@thelovekesh Hmm... the current team barely has the bandwidth to keep up with regular maintenance and security issues, let alone deal with reviewing and maintaining new features.