A second abstract "buffered" HTTP client protocol

Let's discuss having a second protocol for fully buffered requests and responses, likely without trailer support, that many existing clients could conform to today, even without supporting streaming and trailers.

Of course, a concrete client could then implement both the full streaming client protocol and this buffered one, and perform optimizations for the buffered code path.

This is to ensure that clients incapable of implementing the base behavior of the streaming client still have a way to participate, instead of implementing a non-compliant "streaming" client that doesn't deliver trailers.