fix: decode extractor responses with declared charset

[tam1m]

Searching for anything non-ASCII turned the suggestions into � (U+FFFD) chars. Googles suggestions endpoint answers in a locale dependent charset (ISO-8859-1, Shift_JIS or windows-1251), but OkHttpExtractorResponseMapper decoded every body as UTF-8.

The mapper now decodes with the charset from the response Content-Type, falling back to UTF-8 when nothing is declared, so all other traffic is unchanged.

The mapper sits in front of all extractor traffic, but all the other endpoints already answers in UTF-8 afaik, so really only the suggestions endpoint is effected here.

Added regression tests in OkHttpExtractorResponseMapperTest.

To test the upstream endpoint:

curl -sD /tmp/headers 'https://suggestqueries.google.com/complete/search?client=youtube&jsonp=JP&ds=yt&q=%C3%8B' -o /tmp/body
grep -i content-type /tmp/headers
xxd /tmp/body | head -2
iconv -f iso-8859-1 -t utf-8 /tmp/body | head -c 80

1. query is Ë (%C3%8B)
2. Headers say ISO-8859-1
3. hexdump shows 0xCB byte
4. iconv decodes it the same way the mapper does now

The charset also seems to follow the requesters locale:

curl -sD - -o /dev/null -H 'Accept-Language: ja' 'https://suggestqueries.google.com/complete/search?client=youtube&ds=yt&q=test' | grep -i content-type
curl -sD - -o /dev/null -H 'Accept-Language: ru' 'https://suggestqueries.google.com/complete/search?client=youtube&ds=yt&q=test' | grep -i content-type

First returns Shift_JIS and second returns windows-1251. Just here to demonstrate locale dependency. We never send one though, so ISO-8859-1 is all we ever see.

[Priveetee]

Thx a lot for ur contribution, merging to dev :) !