Criterion allows us to crank up the sampling size and confidence, which is important for these kinds
of microbenchmarks that can have high variance. It also has other bells and whistles like tracking
relative performance between runs, which can be very helpful for development.

Per discussion in Discord, the presence of pico in these benchmarks has outlived its usefulness;
we're now primarily concerned with the relative performance of httparse between changes.

This fixes cases where the parser would accept non-compliant request lines including empty methods
and paths.

For the `token` grammar, [the spec][spec-token] is:

```
  token          = 1*tchar
```

`1*` is shorthand for one-or-more, so the empty string is not a valid `token`.

For the path component of the request line, [the spec][spec-path] we're concerned with the
`absolute-path` grammar:

```
  absolute-path = 1*( "/" segment )
```

While `segment` might be empty, there must be at least a `"/"` for it to be syntactically valid.

I've added tests for these cases and their combination, and had to update the expected error of one
of the existing URI tests which now fails sooner due to the empty path.

[spec-token]: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#tokens
[spec-path]: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#uri.references

These new flags set whether multiple spaces are allowed as delimiters in request lines and response
status lines.

The latest version of the HTTP/1.1 spec ([request lines][spec-req], [response status
lines][spec-resp]) allows implementations to parse multiple whitespace characters in place of the
`SP` delimiter in the response status line, including:

> SP, HTAB, VT (%x0B), FF (%x0C), or bare CR

This option relaxes the parsers to allow for multiple spaces, but does *not* allow the delimiters to
contain the other mentioned whitespace characters. We'd rather wait for someone to have a concrete
use case before deciding to support that, as allowing chars like `\r` raises serious security
questions as described by the spec.

Happily this seems to be a performance _improvement_ rather than a regression even when the new
flags are disabled (results vs 6f6ff10):

```
req/req                 time:   [292.13 ns 295.81 ns 301.23 ns]
                        thrpt:  [2.2261 GiB/s 2.2668 GiB/s 2.2954 GiB/s]
                 change:
                        time:   [-13.390% -12.468% -11.159%] (p = 0.00 < 0.05)
                        thrpt:  [+12.561% +14.244% +15.460%]
                        Performance has improved.

req_short/req_short     time:   [62.834 ns 62.992 ns 63.188 ns]
                        thrpt:  [1.0023 GiB/s 1.0054 GiB/s 1.0079 GiB/s]
                 change:
                        time:   [-11.112% -9.9009% -8.9416%] (p = 0.00 < 0.05)
                        thrpt:  [+9.8196% +10.989% +12.501%]
                        Performance has improved.

resp/resp               time:   [303.51 ns 304.23 ns 305.34 ns]
                        thrpt:  [2.1320 GiB/s 2.1398 GiB/s 2.1449 GiB/s]
                 change:
                        time:   [-12.059% -11.512% -11.016%] (p = 0.00 < 0.05)
                        thrpt:  [+12.379% +13.010% +13.713%]
                        Performance has improved.

resp_short/resp_short   time:   [67.521 ns 67.686 ns 67.929 ns]
                        thrpt:  [1.2476 GiB/s 1.2521 GiB/s 1.2552 GiB/s]
                 change:
                        time:   [-9.1562% -8.7366% -8.3331%] (p = 0.00 < 0.05)
                        thrpt:  [+9.0906% +9.5730% +10.079%]
                        Performance has improved.
```

I haven't thrown it into godbolt or anything yet, but I suspect something about this change triggers
a different inlining behavior compared to the baseline.

[spec-req]: https://httpwg.org/http-core/draft-ietf-httpbis-messaging-latest.html#rfc.section.3.p.3
[spec-resp]: https://httpwg.org/http-core/draft-ietf-httpbis-messaging-latest.html#rfc.section.4.p.3