utils.py: default to utf-8 for text/csv (#5746)

This is a super quick attempt to address https://github.com/psf/requests/issues/5746 -- an invitation for feedback. Would appreciate your opinions. Thanks!

(happy to add tests, changelog entry, etc -- brief instructions appreciated)

I believe the last change we accepted along these lines was contentious and broke things. Plus 7111 is likely not widely implemented by folks distributing `text/csv` files at this point given it's recency (and given that 16+ year old RFCs aren't widely implemented either). I'm mildly -1 on accepting this

@sigmavirus24 thanks for the feedback. I share the conservative approach.

Do you see a different method that fixes the specific example given in #5746 (Google Sheets CSV export) while minimizing risk for breakage?

Just hypothetically.. what kind of breakage and unintended change in behavior would we be talking about? UTF-8-decoding byte sequences that would otherwise be... how-decoded? :)

So this function will override logic if we could otherwise detect it from the `Content-Type` header. This means if someone is using UTF-16, UTF-32 or some other encoding that's not decode-able by UTF-8 then the Response.encoding value which was previously detected correctly will now always be `utf-8` which will fail if they try to access `text`. 

> if we could otherwise detect it *from the Content-Type header*.

(emphasis mine)

Just to be sure: you agree that the new code path would not trigger when `charset` is _not_ set in the `Content-Type` header, right? This takes precedence:

```python
    if 'charset' in params:
        return params['charset'].strip("'\"")
```

How would the library, right now, automatically detect for example `UTF-16` in the absence of `charset`?

I have just noticed that the patch as proposed would not change behavior for `text/csv`, because this condition takes precedence:

```
    if 'text' in content_type:
        return 'ISO-8859-1'
```

That is, when `charset` is _not_ present in the `Content-Type` header, but when the substring `text` is found in the `content_type` string (it is an object of type `str`, and not a different kind of iterable, right?) then ISO-8859-1 is chosen for decoding for decoding the byte sequence.

The ` if 'text/csv' in content_type` would need to be added before that so that it can itself take precedence.

Is it fair to say that currently in all cases where the `Content-Type` header contains the word "text" but does _not_ specify a `charset` the library picks ISO-8859-1?

If the answer is a definite 'yes' that would be good news, because ISO-8859-1 is a subset of UTF-8.

> Is it fair to say that currently in all cases where the `Content-Type` header contains the word "text" but does _not_ specify a `charset` the library picks ISO-8859-1?

So that's only one part of it. The other half of this coin is that people probably shouldn't be using [`Response.text`](https://github.com/psf/requests/blob/8c211a96cdbe9fe320d63d9e1ae15c5c07e179f8/requests/models.py#L852-L874) because it forces to a string however possible and is likely lossy.

But yes, latin-1 would be the default if `charset` isn't specified which is the right approach for most servers to take. 

I agree with Sigmavirus24 that this isn't the right approach. The risk being introduced doesn't outweigh the problem it solves. If this does eventually solidify as widely implemented, we can consider it for a major release but it won't be accepted for Requests 2.x.