Fix repeated HTTP fields and qvalue parsing

[tomcatzh]

What changed

• combine all repeated Accept, Accept-Encoding, and If-None-Match field
  lines before evaluating negotiation or validators
• replace floating-point qvalue parsing with the RFC 9110 grammar and a fixed
  0–1000 representation
• add unit and public HTTP-contract coverage for split field lines and invalid
  qvalues
• document the fixes in the unreleased changelog

Why

HTTP recipients may combine repeated list-valued field lines without changing
their semantics. Reading only the first stored value could ignore a later
acceptable representation, HTML media range, or matching validator.

The former floating-point parser also clamped values outside the HTTP qvalue
grammar. For example, 1.0000 could become fully acceptable even though
senders may emit at most three fractional digits.

Impact

The public API is unchanged. Negotiation and conditional requests now behave
consistently for repeated fields, and malformed qvalues are treated as zero
quality rather than normalized into valid preferences.

Validation

• make check — 9 unit tests, 10 HTTP contract tests, Clippy with
  -D warnings, rustdoc
• cargo package --allow-dirty — 45 packaged files and verified package build
• make test-nginx — Nginx 1.29.8-alpine, 8 MIME types,
  identity/gzip/Brotli, MISS/HIT/REVALIDATED, fresh-cache 304