Decide how strict to control which headers runtimes are permitted to return

[rylev]

The current status quo in the conformance tests is to exhaustively check headers erroring if a header is set when the test does not specify that it can be. The tests have some flexibility in that they can specify the following:

• A header is set but it doesn't matter what the value is
• A header can be set but if its missing it's fine
• A header must be set and its value equal to what is specified.

It is likely that for some tests, we'll want to be strict about some headers, but for many other tests we don't really care.

[lann]

This is just a theoretical problem until we run into actual issues, but there are a bunch of HTTP semantic equivalences that strict header checking wouldn't allow for; off the top of my head:

• Different transfer-encoding of the same body (unless a particular test is checking that explicitly!)
• Header value merging
• Case insensitivity for certain header values (media types)

Additionally, we should decide how strict we want "conformance" to be about extra headers like distributed tracing IDs.