New HTTPHeaderDict class for response headers with multiple header value support

I personally wanted something like this while writing [my own Requests-related library](https://github.com/the-allanc/pyriform), but I can see other people also have wanted something like this - #3957 and #4214 both mention it in terms of handling `Set-Cookie` headers.

I've written an subclass implementation of `CaseInsensitiveDict` which is compatible with all the current usage (according to the tests), but adds new methods for clients that want to deal directly with unjoined headers. I've also added quite a number of tests and made slight changes to the documentation in relation to it.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=h1) Report
> Merging [#4282](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/fdb9b753b47e7abead1ec75d860c9c9b929ca5f5?src=pr&el=desc) will **increase** coverage by `0.26%`.
> The diff coverage is `98.36%`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4282/graphs/tree.svg?src=pr&token=mZGswIiXLa&width=650&height=150)](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master    #4282      +/-   ##
==========================================
+ Coverage   88.66%   88.93%   +0.26%     
==========================================
  Files          18       18              
  Lines        2021     2079      +58     
==========================================
+ Hits         1792     1849      +57     
- Misses        229      230       +1
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/adapters.py](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=tree#diff-cmVxdWVzdHMvYWRhcHRlcnMucHk=) | `92.99% <100%> (ø)` | :arrow_up: |
| [requests/structures.py](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=tree#diff-cmVxdWVzdHMvc3RydWN0dXJlcy5weQ==) | `98.97% <98.3%> (-1.03%)` | :arrow_down: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=footer). Last update [fdb9b75...5cbd6dd](https://codecov.io/gh/requests/requests/pull/4282?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


I generally like this. 

This should be a PR against the `proposed/3.0.0` branch, though, not master. 

I also wouldn't be opposed to the name `CaseInsensitiveMultiDict`

I haven't checked, but I'd like this API to be compatible with Flask/Werkzeug's MultiDict, if possible. 

In general though, this looks real solid! ✨🍰✨

Good job with the tests too :cookie:

You get a cookie. 

I also really like that this is a subclass of `CaseInsensitiveDict`. 

With regards to MultiDict in werkzeug, it uses `getlist` and `setlist`. HTTPHeaderDict in urllib3 also uses `getlist` (it has no `setlist` equivalent). I was going to use the same naming convention, except that I'm storing and returning tuples.

I did have concerns about the lists being modified outside of HTTPHeaderDict (which tries to enforce that only string types are present). So it's either a case of::
- Leaving the names as they are.
- Using "list" names even though we're returning tuples.
- Rename the methods and return lists (either copies or the underlying sequence).

Renaming `HTTPHeaderDict` to `MultiCaseInsensitiveDict` is a bit more contentious - because it's not a generalised class (it's intended for string values only).

The main intent was to keep the exact same behaviour that we had in requests for response header processing, but to handle the concatenation of values ourselves (rather than letting urllib3 to do it for us). The concatenation of values is specific to HTTP headers (comma separation).

I could refactor part of the code and extract the `Multi...` part of the class into a separate class, and then inherit from that. We would need to decide what happens for general item access (I note that `MultiDict` returns just the first item).

I think what you have is good, then, unless we cast to lists. 

Which seems silly to me. 

I just wanted to provide a very familiar API to those who have used similar APIs before. 

I've just always liked the name `CaseInsensitiveMultiDict`, and wish we had it. This is good though.

OK, I've renamed the methods to `getlist` and `setlist`, and they now return lists, so that's more consistent with other implementations. Both urllib3 and werkzeug provide copies of the sequences, so we also do the same (we still use tuples under the hood, which makes me happy).

I was going to try and extract some of the code into a `CaseInsensitiveMultiDict` class, but there's too much nuance in trying to determine the best behaviour for such a generalised class (especially for the `extend` method, which tries to distinguish between items and sequences - how should it behave if you're using the dictionary to store sequences of sequences?)

I've made sure that this class is entirely backwards compatible with what we were using before - I wrote some of the tests using `CaseInsensitiveDict` and they still worked when I switched to `HTTPHeaderDict` for responses. Are you sure that you still want it against the `proposed/3.0.0` branch? 

@the-allanc definitely :)

P.S. good work!

In that case, I'm closing this pull request in favour of #4290.