Fix ASCII case-fold collision between distinct tchar punctuation bytes

[shoemoney]

Motivation:

ByteCollectionUtils.swift's compareCaseInsensitiveASCIIBytes folds case by
masking every byte with & 0xdf (clearing bit 0x20). That bit is what
distinguishes an ASCII lowercase letter from its uppercase form, but it is
also the only bit separating several unrelated punctuation bytes from one
another:

byte	hex	& 0xdf	byte	hex	& 0xdf
^	0x5E	0x5E	~	0x7E	0x5E
[	0x5B	0x5B	{	0x7B	0x5B
]	0x5D	0x5D	}	0x7D	0x5D
\	0x5C	0x5C	|	0x7C	0x5C
@	0x40	0x40	`	0x60	0x40

Every byte in the right-hand column masks down to the same value as its
left-hand partner, so the current implementation treats them as identical.
All ten of these bytes are legal tchar characters in an HTTP header field
name per RFC 7230 §3.2.6, and are accepted as such by NIO's own header-name
validator (HTTPHeaders+Validation.swift). The result: two genuinely
different header names collide.

var headers = HTTPHeaders()
headers.add(name: "X-Foo^Bar", value: "caret-value")

headers.first(name: "X-Foo~Bar")   // returns "caret-value" -- wrong header!
headers.contains(name: "X-Foo~Bar") // returns true -- wrong header!

Because compareCaseInsensitiveASCIIBytes backs String.isEqualCaseInsensitiveASCIIBytes,
which backs HTTPHeaders's name comparisons, this collision propagates to:

• HTTPHeaders.first(name:)
• HTTPHeaders.subscript(_:) / subscript(canonicalForm:)
• HTTPHeaders.contains(name:)
• HTTPHeaders.remove(name:)

Modifications:

Replace the unconditional & 0xdf mask with a helper that only clears bit
0x20 when the byte is actually an ASCII lowercase letter (a...z),
leaving every other byte — punctuation included — untouched:

@inline(__always)
private func uppercaseASCIILetter(_ byte: UInt8) -> UInt8 {
    switch byte {
    case UInt8(ascii: "a")...UInt8(ascii: "z"):
        return byte & 0xdf
    default:
        return byte
    }
}

This is a single range check (matches the UInt8(ascii:) range-switch idiom
already used elsewhere in NIOHTTP1, e.g. HTTPHeaderValidator.swift and
HTTPHeaders+Validation.swift), so it stays branch-light and does not
regress the hot path both the fast (withContiguousStorageIfAvailable) and
fallback (elementsEqual) comparison loops sit on.

Result:

Header names that differ only by one of these five punctuation pairs are no
longer treated as equal, while ASCII letter case-folding (the actual purpose
of the function) is unaffected.

Tests:

Added a test to Tests/NIOHTTP1Tests/ByteBufferUtilsTest.swift exercising
compareCaseInsensitiveASCIIBytes directly against all five colliding pairs
(plus a same-byte and letter-case sanity check), and a test to
Tests/NIOHTTP1Tests/HTTPHeadersTest.swift exercising the bug through the
public HTTPHeaders API (first(name:), contains(name:),
subscript(canonicalForm:), remove(name:)) with the ^/~ pair.

Confirmed both new tests fail against the old implementation (5 assertion
failures in the byte-level test, 4 in the HTTPHeaders-level test) and pass
after the fix, with the full NIOHTTP1Tests suite green.