Respect q=0 in gzip content negotiation

[freakes]

Summary

Fix gzip middleware to respect q=0 values in the Accept-Encoding header.

Problem

According to RFC 9110, an encoding with q=0 is explicitly unacceptable. The current implementation does not respect this quality value and may enable gzip even when the client sends:

Accept-Encoding: gzip;q=0

Solution

Update the gzip negotiation logic to honor q=0 quality values and skip gzip when it is explicitly marked as unacceptable.

Testing

• added a regression test covering Accept-Encoding: gzip;q=0
• go test ./middleware

[aldas]

which real-world client sends Accept-Encoding: gzip;q=0?

[aldas]

similar PR #3021

[freakes]

@aldas
I don't know of a mainstream browser that sends gzip;q=0 by default.
My motivation was standards compliance, but there's also another issue with the current implementation: it uses a substring match, so values like x-gzip or supergzip also enable gzip even though they are different coding tokens.
Since Accept-Encoding is a structured header, I thought it would be better to match coding tokens explicitly rather than relying on strings.Contains.

[aldas]

Maybe this thing could be helper function that people that need this feature could use in Skipper function.

At the moment the client can opt out from gzip is by not sending gzip Accept-Encoding so doing all this "acrobatics" to support disabling gzip with Accept-Encoding: gzip;q=0 feels little bit overdoing it.