Title: In HTTP/1.1, envoy should pass-through header capitalization unmodified (without lower-casing)

Description:
This ticket is related to #6485, which was declined; with a renewed focus on the core point of discussion. HTTP/2 requires all header fields to be lower-cased. However, the HTTP/1.1 standard is far less opinionated on the issue. On the one hand, it specifies that "field names are case-insensitive"; and on the other, it states:

Applications ought to follow "common form", where one is known or indicated,
when generating HTTP constructs, since there might exist some implementations
that fail to accept anything beyond the common forms.

Which could be interpreted to mean Train-Case as a default, since that is the form most commonly referred to in documentation of various headers (e.g. Content-Type).

Even if we take the standard to be ambiguous in this respect, there are major tools that deliver headers exactly as they were sent without modifying their case (e.g. php request headers). This leads to real-world client code often being "broken" (in terms of API standard) by expecting headers in a specific casing.

While it may be reasonable to expect an organization to be able to internally fix its own client code, if Envoy is being used for APIs served externally to that organization, it will lead to avoidable -- sometimes show-stopping bugs. In our experience, we have found that trying to migrate to Envoy introduced a breaking change to our external APIs by hiding an optional header from certain client integrations (e.g. PHP). This failure case is silent and produces no errors on either side of the integration (uh-oh). As far as our client code is concerned, it's simply as if the header was never sent!