Check header fields and further requests in resolve criteria

[fabianekc]

Adapts dpplint to dpp-criteria 4c155ee (PRs 1 and 3 there) for check type resolve.

Changes

• expect.headers: exists, equals, contains, matches, optional severity: warning. Field names are matched case-insensitively; several fields with the same name are combined into one value separated by ", ". A missing field fails every assertion except exists: false.
• further_requests: sent after the first request with their own Accept header and expect, evaluated independently of it; severity: warning turns every failure of that request into a warning, including a failed retrieval.
• Overall result: failed if a check with severity error fails, otherwise warning if a check with severity warning fails, otherwise passed.
• expect keys that resolve does not evaluate (json, body_equals_step) make the criterion skipped with a reason instead of passing silently.
• HttpResolver keeps the header fields of the final response.

Tests

• New unit tests for every header operation (missing field, repeated fields, case), for further_requests with and without severity, and for the overall result.
• Test suite with dpp-criteria 4c155ee: 107 runs, 0 failures, 0 errors.
• DPP-DAT-016 v2 against https://dpp.oydapp.eu/01/09520123456788/21/000001: failed. The request with Accept text/html returns application/json (violation), and Vary lists only Origin (warning). The request with Accept / returns application/json as expected.

Open questions for dpp-criteria

• matches on header values: search within the value or full match, and which regex dialect.
• Separator used when combining repeated fields for equals.
• json and body_equals_step are allowed in resolve expect by the shared schema definition, but their meaning there is undefined.
• Header assertions after redirects: final response (as implemented) or the redirect response.

Results are automated checks only; they are no certification and establish no presumption of conformity.