Document HTTP encoding limitations for Fetch plugins

[zmughal]

In a particular case, I had a server that was always returning a response with
Content-Encoding: gzip:

curl -sS -D - "https://www.swi-prolog.org/download/stable/src/" -o /dev/null

regardless of content negotiation via Accept-Encoding: in the request.

Well, it was. This got fixed yesterday so it no longer applies. But
continuing with the issue...

---

Since the content negotiation was not working properly, I believe that using
Fetch::HTTPTiny, Fetch::CurlCommand, or Fetch::Wget plugins would break
when trying to pass the text/html content as they would not be able to decode
the content. By changing the Fetch plugin to Fetch::LWP, the response would
be decoded properly.