HttpClient has no connection pool — requestsBufferSize() unusable from async code

Each HttpClient instance owns a single TCP connection. Getting concurrent capacity requires maintaining multiple HttpClientPtr instances manually. The only API to inspect queue depth is requestsBufferSize(), but it blocks the calling thread when called from outside the client's event-loop:

```
std::size_t requestsBufferSize() override
{
if (loop_->isInLoopThread())
return requestsBuffer_.size();

std::promise bufferSize;
loop_->queueInLoop([&] { bufferSize.set_value(requestsBuffer_.size()); });
return bufferSize.get_future().get(); // blocks calling thread
}

```

Since sendRequest always dispatches via runInLoop, the caller is never on the client's loop thread — meaning requestsBufferSize() always takes the blocking path. This makes least-loaded selection impossible in async code; the only option is cycling through connections blindly.
Additionally, a long-polling connection (30s timeout) occupies one of those connections entirely, requiring it to be isolated on a separate EventLoopThread to avoid starving the rest of the pool.
Both problems go away with HTTP/2 — a single connection handles concurrent streams natively, no manual pool needed. PR #1554 merged HTTP/2 support but newHttpClient still has no parameter to enable it as of v1.9.13. Is there a stable path to opt into HTTP/2, and if not, what is the timeline for #2037?