fix core: don't depend on HTTP/2.0 pseudo-header field order

[SSE4]

The server matches a request against its handlers as soon as the :path
pseudo-header is decoded, using whatever method has been parsed by that point.
RFC 9113 §8.3 doesn't fix an order among pseudo-header fields, and clients
disagree: curl sends :method first, h2load sends :path first. As a result
every h2load request gets 405 Method Not Allowed — matching runs with the
default HttpMethod::kUnknown and the cached result is never revisited:

$ h2load -n 1 -c 1 -v http://localhost:8080/ping
[stream_id=1] :status: 405

This matches the handler once both :method and :path are decoded. Since
pseudo-header fields precede all regular fields, that is the earliest correct
moment in every order: the per-handler request limits then cover the rest of
the header block, and a doomed request (405/404) is known as early as
possible — no resource-usage regression versus the old eager match. The
remainder of the block still has to be decoded either way (HPACK is stateful;
abandoning a block midway would desync the connection) and is bounded by
max_headers_size. A call at end-of-header-block (OnFrameRecv, fires after
all CONTINUATION frames) remains as a safety net; matching can't be postponed
to FinalizeRequest because the per-handler limits must be installed before
the request body's DATA frames arrive.

Tested with two new parametrized tests in the http2server functional suite:
the same request over four pseudo-header orders (h2load's exact order
included), as GET and as POST with a request body — the latter checks that
the per-handler limits are installed before the body arrives. Without the fix
the four :path-before-:method cases fail with 405; with it all pass. The
rest of the http2server suite (h2spec included) and the http2/connection unit
tests pass unchanged. Also verified with stock h2load under load: 2M
requests, 100% 200.

closes: #1300