Broad changes to handle case properly in headers and parameters

[tjquinno]

Resolves #5149

Header names should be case-insensitive. What Helidon calls "parameters" (query parameter, path params) should be case-sensitive. (Note that our use of "parameters" in this context does not correspond to other usages such as https://httpwg.org/specs/rfc9110.html#parameter, in which a parameter is an optional addition to the value of a "field"--basically, an addition to a header value.)

This PR fixes problems in both headers and parameters.

I tried to be fairly minimally-invasive as possible while still addressing the problems. Still, there are quite a few changes needed to fix this situation.

Some highlights:

Key changes are in helidon-common-http but other components are affected as well.

• The new class HashHeaders extends HashParameters. Each now creates the correct type of Map (case-sensitive or -insensitive) in separate protected factory methods. Various classes related to writeable headers now extend HashHeaders (instead of extending HashParameters as they did before) and so now inherit the correct case-insensitive behavior.
• The new class ReadOnlyHeaders extends ReadOnlyParameters. Each now creates the correct type of Map in protected factory methods for various purposes. Various classes related to read-only headers now extend ReadOnlyHeaders to inherit the correct case-insensitive behavior.
• Several other classes are changed to use Headers or its various implementations rather than Parameters or its counterparts so the data is handled in the (correct) case-insensitive manner.
• Tests:
  • Lots of new tests check for the appropriate behavior in many classes related to headers and parameters. helidon-config-testing now contains a new CaseSensitivityTester utility class and is a new test-scoped dependency for several components.
  • A new tracing-specific test checks for proper B3 propagation from client to server.

Some lower-level details:

Parameters now extends Iterable<Map.Entry<String, List<String>>> and provides a default implementation of iterator. Adding this extends reduces the need to create temporary data structures in other code. For our classes which implement Parameters, this PR includes overrides of iterator with more efficient code than the default.

I kept some methods that the IDE shows as no longer used because, although unlikely, developers might have written extensions of our classes and overridden those methods. Removing them would be a backwards-incompatible change.

There is abundant opportunity to--but I did not--refactor further to reduce even more code duplication. For example,

• Header and Parameters could extend a common parameterized interface
• HashParameters and HashHeaders could extend a common abstract superclass
• Same for ReadOnlyParameters and ReadOnlyHeaders

But doing that refactoring would be quite a bit more far-reaching than the proposed changes here. Plus, header handling is much different in 4.x so further major refactoring work in 3.x would not carry forward and is likely not worth the investment.

[tomas-langer]

No need to deprecate, 4.0.0 will not use this class at all