downloads: don't use Content-Length as progress total when Content-Encoding is set

[alliasgher]

Summary

Fixes #1642.

When a server sends Content-Encoding: gzip (or any encoding), the requests library transparently decompresses the response body. The bytes written to disk are the decompressed size, which is usually much larger than the compressed Content-Length. Using Content-Length as the expected total causes downloader.interrupted to return True at the end of an otherwise successful download, producing a false "Incomplete download" error.

Before

$ http --download http://server/file.gz
Downloading 5 MB to data.json.gz
❯ Incomplete download: size=5084527; downloaded=42846965

After

Progress is shown without a denominator (same as chunked responses with no Content-Length), and no spurious error is emitted.

Fix

Skip Content-Length as the progress total whenever Content-Encoding is present.

The existing # FIXME: some servers still might send Content-Encoding: gzip comment (which referenced issue #423) is replaced by this explicit guard.

Tests

Added test_download_with_content_encoding_does_not_report_incomplete which:

• sets Content-Length: 5 and Content-Encoding: gzip
• writes 8 bytes of "decompressed" data (> 5 bytes)
• asserts downloader.interrupted is False

[alliasgher]

The 2 failing tests (test_terminal_output_response_charset_detection[big5-...] and test_terminal_output_request_charset_detection[big5-...]) are in test_encoding.py and pre-date my changes — they fail on the upstream master branch too and are unrelated to downloads or cli/utils. My changes only touch httpie/downloads.py, httpie/cli/utils.py, and the corresponding test files.