Accept-Encoding header parsing and interpretation

### Is your feature request related to a problem?

Forgive me - parts of this might be considered bug fix and parts feature request, but they are highly related and intertwined in the same code. These are things I noticed while working on #8063.

- Dynamic compression via `enable_compression()` will compare `Accept-Encoding` case-insensitively, but retrieving static compressed files does not it should be case-insensitive per [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-accept-encoding)).
- When the `force` parameter is used in `enable_compression()`, it does not even consider `Accept-Encoding`. I fail to see any real use case for this and feel it should be treated like a preference instead (i.e. override the default preference to use `deflate` to something else). If Brotli were implemented, it may very well be more performant than `deflate`, so preferring it might be desirable, but then the server no longer supports legacy browsers without Brotli support.
- AFAICT, there is no proper parsing of the `Accept-Encoding` field per [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-accept-encoding). There is simply an `in` operator test of the string. For example:
- ❌ If the header is not set, it indicates any encoding is okay, but the server currently will only send uncompressed. Technically that's fine, but if a static compressed version exists but the uncompressed version does not (e.g. to save disk space), then the compressed version should be sent.
- ❌ "*" in the field selects any encoding **not** explicitly listed.
- ❌ Each coding is permitted to have a quality factor (e.g. "br;q=1, deflate;q=0, *;q=0). Higher quality factors should be preferred over lower ones if supported by the server, and ";q=0" says not to send that encoding.
- ✔️ If the header is empty ("") then no compression should be sent.

### Describe the solution you'd like

- [x] `Accept-Encoding` should be treated case-insensitively when returning static compressed files.
- [ ] The `force` parameter to `enable_compression()` should really act like a preference, not an override (i.e. it should not be forced if the encoding is not supported per the `Accept-Encoding` request header).
- [ ] Parse and interpret the header per [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-accept-encoding) with quality factors, "*", etc. Send a 415 response if merited.

### Describe alternatives you've considered

None for the first 2, but admittedly the parsing issue is more or less a moot point since most clients always send the header with an explicit list and no quality factors (i.e. "gzip, deflate, br").

### Related component

Server

### Additional context

n/a

### Code of Conduct

- [X] I agree to follow the aio-libs Code of Conduct