Speedup HTTP headers lowercase transformation

[franz1981]

In some simple HTTP 2 hello world benchmarks, HttpUtils::toLowerCase has pop-up due to how Quarkus handle HTTP headers using Jax-RS HTTP header name constants ie using capital letters in Strings eg "Content-Type".

This is speeding up the String lowercase transformation case improving the others, where possible.

baseline:

Benchmark                                       (lowerCase)   (type)  Mode  Cnt   Score   Error  Units
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase        false    ascii  avgt   20  29.698 ± 0.195  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase        false   string  avgt   20  23.967 ± 0.791  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase        false  builder  avgt   20  24.155 ± 0.905  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase         true    ascii  avgt   20   6.625 ± 0.008  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase         true   string  avgt   20   4.932 ± 0.015  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase         true  builder  avgt   20   5.654 ± 0.021  ns/op

b2925a8 :

Benchmark                                       (lowerCase)   (type)  Mode  Cnt   Score   Error  Units
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase        false    ascii  avgt   20  10.988 ± 0.258  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase        false   string  avgt   20  13.255 ± 0.111  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase        false  builder  avgt   20  24.846 ± 1.290  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase         true    ascii  avgt   20   6.107 ± 0.007  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase         true   string  avgt   20   5.078 ± 0.053  ns/op
HttpUtilsAsciiToLowerCaseBenchmark.toLowerCase         true  builder  avgt   20   5.619 ± 0.017  ns/op

This change is kind-of related to https://github.com/quarkusio/quarkus/pull/37619/files#diff-7cd9e11ea75ab750663bd15870c0749df275c32fd3d8eb2dfdc8eb706e4db540L499
which, instead, try to address it by forcing to use the same AsciiString of vertx, but introducing some ugly APIs which doesn't fit with the rest.

That's why I think that improving on Vertx side is more beneficial for this