append previous url fragment on redirect

This PR should address #4443 by appending the original request's fragment to subsequent redirects, unless a new fragment is provided in the Location header. This behaviour should bring us into compliance with [RFC 7230 § 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). I also wrote a test to confirm we don't send fragment information to new servers, our underlying implementation strips that.

One outstanding question I do have though is about chained redirects. 

-----

Let's say we make a request (`http://url#alice`) and get a 302 response (`http://new_url#bob`). We would leave `#bob` as the fragment for the second request. When we request `http://new_url#bob`, we get back another 301 to `http://final_url/`. Do we append `alice` or `bob` at this point? 

I went with the assumption that the "original" request is the first one in the chain. I could see an argument that all requests are stateless though, and that the `new_url#bob` is the only originating request in scope for the second redirect.

I went ahead and did [some testing](https://gist.github.com/nateprewitt/233301041bbd70cc53ef31a807d85bc7) to see how other user agents handle this. All of the major browsers except Safari will append `#bob`, so I've updated the logic and extended the tests to reflect that.

I could see having the expected fragment being modified in transit being confusing for end-users, but it's probably best we behave like the rest of the ecosystem unless we have a strong reason not to.

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

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

```diff
@@            Coverage Diff             @@
##           master    #4452      +/-   ##
==========================================
+ Coverage   90.14%   90.18%   +0.03%     
==========================================
  Files          15       15              
  Lines        1543     1548       +5     
==========================================
+ Hits         1391     1396       +5     
  Misses        152      152
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4452?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/sessions.py](https://codecov.io/gh/requests/requests/pull/4452/diff?src=pr&el=tree#diff-cmVxdWVzdHMvc2Vzc2lvbnMucHk=) | `95.63% <100%> (+0.08%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4452?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/4452?src=pr&el=footer). Last update [f89c325...f60324a](https://codecov.io/gh/requests/requests/pull/4452?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


@sigmavirus24 sorry for the delay. I've been playing around with rfc3986 and empty fragments. The rfc3986 conversion is a little more than I've had time to do right now and seems like a good followup PR.

I have empty fragments working on another branch, but the solution is cluttered and the behaviour around them is mostly undefined.Given that we don't support them currently, I'm going to propose this is the solution we proceed with. If you'd prefer we maintain empty fragments, I'll push up the other branch.

Alright, rebased and merging.