Implements "trailing_headers" for HTTP/2

[tsubakiky]

Summary

HTTP/2 Trailing Headers Support

This PR adds support for HTTP/2 trailing headers in httpcore. Trailing headers are now properly received, processed, and made available in the response extensions.

Background:
I’m currently developing a Connect-protocol–compliant library that doesn’t depend directly on grpcio. I’ve implemented the client with httpcore, but because I needed to receive trailer headers in HTTP/2 streaming, I introduced the following modifications.

https://connectrpc.com/docs/protocol

Changes

• Added support for processing h2.events.TrailersReceived events
• Store trailing headers per stream ID, filtering out pseudo-headers
• Expose trailing headers in response extensions as trailing_headers
• Improved response body streaming to handle trailing headers that arrive after headers but before end of stream
• Added comprehensive test suite for trailing headers functionality

Implementation Details

• Modified HTTP2ConnectionByteStream to update response extensions when trailing headers are received
• Added reference tracking between response objects and their byte streams to ensure trailing headers can be properly attached
• Ensured proper cleanup of trailing headers when responses are closed
• Maintained consistent implementation between sync and async versions

This implementation safely handles HTTP/2 trailing headers according to the HTTP/2 specification, ensuring all header data is correctly accessible to clients.

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[zchee]

@tomchristie @graingert Sorry for the noisy, but gentle ping.

[tomchristie]

Thanks. Given the overhead this functionality looks like an unwin for most users.

[tsubakiky]

@tomchristie
Thank you for your feedback.

How about I modify the implementation so that the client only processes response trailers when the request includes the header {"TE": "trailers"}? That way, there should be no additional overhead in the typical case.

I noticed you tried a similar approach before in this PR:
#582