fix: Respect caller-supplied Content-Encoding for pre-compressed request bodies (#997)

A caller-supplied `Content-Encoding` now marks the request body as
already encoded, so the client forwards it untouched instead of dropping
the header (since #987) or overwriting it (before #987).

## How it works

- Precedence in `_prepare_request_call`: caller `Content-Encoding` ->
content-type heuristic -> size threshold -> compress. The header alone
is the "hands off" signal, as in `apify-client-js`, so no opt-out
parameter lands on the public `HttpClient` ABC. Lookups go through a new
case-insensitive `_get_header`.
- The header is forwarded verbatim, so encodings the client ships no
compressor for (`deflate`) work too, and `identity` becomes a
per-request opt-out.
- `KeyValueStoreClient.set_record` gains a `content_encoding` argument
(sync and async). Without it the behavior is barely reachable, as no
public resource method took per-request headers.

## Notes

- Not breaking: #987 and #988 are both still in the unreleased 3.1.2
section, so the header-dropping behavior never shipped.
- Three tests from #987 flip. Two collapse into one parametrized
`test_prepare_request_call_keeps_caller_content_encoding` covering their
cases plus `identity` and `deflate`.
- A `Content-Encoding` passed to the client constructor counts as
caller-supplied on every request, as in JS, where axios config headers
include the client defaults.
- The compression guide drops a claim that file-like values are streamed
and never compressed. Since #965 they're read into memory and compressed
like any other body.
- No integration test: the round trip needs a real token, so the
API-side premise (a `PUT` record honors the header and serves the record
with it) rests on the API docs. The unit tests cover the client side in
full.

Closes #996

*✍️ Drafted by Claude Code*