Add an overall upstream response-header deadline distinct from read_timeout

## What problem does this solve?

Pingora currently exposes `PeerOptions::read_timeout` as a per-read inactivity timeout. That is useful for a silent upstream, but it does not bound the total time spent receiving an incomplete response header when the upstream keeps making small amounts of progress before each individual read timeout expires.

At current `main` commit `09696b51bc59315353d96686355861604d0bb48c`, the HTTP/1 client `HttpSession::read_response()` keeps partial bytes in `response_header_read_buf`, then wraps each `underlying_stream.read_buf(...)` in a fresh `read_timeout`. Any successful read loops back to parsing and receives a new timeout. The public peer documentation and both H1/H2 client fields also describe `read_timeout` as resetting on every read and explicitly not being an overall response-duration timeout.

That means an upstream can send an incomplete response header one byte/fragment at a time, each fragment arriving inside `read_timeout`, and keep a request occupied without ever completing `\r\n\r\n` or violating the inactivity timeout.

This cannot be implemented reliably by a `ProxyHttp` application today: `upstream_response_filter` is invoked only after the response header has arrived, while body filters are later still. `total_connection_timeout` is not a substitute because it bounds connection establishment (including TLS), not the response-header phase.

## Desired behavior

Please consider an additive, explicit **overall upstream response-header deadline** (name/API shape up to maintainers) that is distinct from `read_timeout`.

The important semantics would be:

- the deadline spans repeated successful reads while one response header is incomplete;
- per-read `read_timeout` remains independently useful as an inactivity timeout;
- HTTP/1 and HTTP/2 behavior is explicit;
- informational (1xx) responses have documented semantics: e.g. whether the budget applies independently to each header block or to the entire pre-final-response header phase;
- timeout cancellation is safe and does not leave response-header parsing state or pooled connection reuse in an inconsistent state;
- an unset value preserves current behavior.

A peer option is one possible surface, but an equivalent cancellation-safe hook would also solve the application-level gap if it can actually terminate a pending header read at the overall deadline.

## Reproduction shape

A deterministic regression can use an origin that:

1. accepts the upstream request;
2. starts sending a syntactically valid-but-incomplete status/header block;
3. sends one byte or small fragment every `N` ms where `N < read_timeout`;
4. deliberately withholds the terminating `\r\n\r\n` past the configured overall header deadline.

Expected with a new overall deadline: the request fails at approximately that total header budget even though every individual read made progress inside `read_timeout`.

This is specifically about bounding the **response-header phase**. It is separate from whole-response/body lifetime policy and from application-level streaming semantics.