docs: document cancel safety for client send_request futures

[lihan3238]

Summary

Refs #4054. Documents hyper's cancellation behavior on the two client send_request futures, plus a small crate-level pointer.

Per seanmonstar's suggestion in the issue:

...would it be better to have a small section on the relevant futures about cancellation? Or maybe in combination with a small mention at the crate level, "futures are cancel safe, see individual features for behavior when canceled"

This PR does both.

Changes

src/client/conn/http1.rs — adds # Cancel safety to SendRequest::send_request:

Dropping the returned future is the supported way to cancel an in-flight HTTP/1 request. Because HTTP/1 has no in-protocol way to abort a single request without affecting the shared connection, hyper closes the underlying connection when a request future is dropped before completion. Any subsequent calls on the same SendRequest will return a canceled error.

src/client/conn/http2.rs — adds # Cancel safety to SendRequest::send_request:

Dropping the returned future is the supported way to cancel an in-flight HTTP/2 request. The stream is reset with RST_STREAM (CANCEL error code); the shared connection remains usable for other in-flight and future requests. The peer is notified immediately rather than continuing to send a response body that would be discarded.

src/lib.rs — brief crate-level mention pointing at the per-future docs.

Notes

• Plain code spans (no intra-doc links) in the crate-level note to avoid broken-link warnings when cargo doc runs without --features client.
• Issue author (@jorendorff) said they'd "look into this when I have a chance" 12 days ago — happy to defer or merge this as a starting point. The wording follows the technical content they already laid out in the issue body.
• Scope limited to the client-side cancellation paths the issue author was confident about; server-side behavior left for a follow-up since the issue author noted they hadn't verified it.

[seanmonstar]

Looks great, thanks!