net/http: be stricter about framing-related headers #81595

This is a follow up to #81115.

#81115 describes an issue where:

1. A server sends multiple conflicting Content-Length headers.
2. A reverse proxy, using our HTTP/2 transport implementation, accepts the headers and passes them along to the client (normally, this is okay to do since HTTP/2 framing does not rely on Content-Length headers).
3. An HTTP/1 client, which improperly accepts multiple Content-Length headers (our HTTP/1 transport does not), is now vulnerable to response smuggling.

After #81115, our HTTP/2 transport will no longer forward multiple Content-Length headers, just in case we are forwarding to an HTTP/1 implementation that might be vulnerable to response smuggling.

However, it might be beneficial for us to be stricter about framing-related headers in general:

1. Our server should not send an HTTP/1 response containing multiple Content-Length headers.
2. Consider similar scenarios with non-canonical (e.g., content-length rather than Content-Length).
3. Consider similar scenarios with Transfer-Encoding.

A dedicated attacker can always directly send invalid framing-related headers to the wire regardless of our implementation. But, this can prevent cases where someone using our server accidentally sends bad headers.