Include tests in sdist tarball

Fixes: https://github.com/kennethreitz/requests/issues/4024

# [Codecov](https://codecov.io/gh/kennethreitz/requests/pull/4026?src=pr&el=h1) Report
> Merging [#4026](https://codecov.io/gh/kennethreitz/requests/pull/4026?src=pr&el=desc) into [master](https://codecov.io/gh/kennethreitz/requests/commit/0280a18b53aef5e09fa0a2886077b0ede5e89e79?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

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

```diff
@@           Coverage Diff           @@
##           master    #4026   +/-   ##
=======================================
  Coverage   89.74%   89.74%           
=======================================
  Files          15       15           
  Lines        1940     1940           
=======================================
  Hits         1741     1741           
  Misses        199      199
```



------

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


I'd rather take the recursive-include for now. 

Given that this was overlooked for a year, it seems like an easy place to forget about again. Perhaps simply changing it to `recursive-include tests *` which has worked for `urllib3`? You handle the releases though, so whatever you think works best, I'm on board with.

As for the failure, it's due to our Sphinx dependency in dev-packages. A release that came out today finally broke 2.6 which Sphinx stopped supporting a while ago. We'll likely want to pin it at `<=1.5.5` until we deprecate 2.6 support ourselves.

> Given that this was overlooked for a year, it seems like an easy place to forget about again.

It's especially easy given that tests aren't part of the actual package and should only be included in source archives, not source distributions. But *shrug* I'm not about to have this disagreement with another downstream redistributor.

I'd also like to avoid capping Sphinx to preserve 2.6 support. I'd rather Pipfile joined the time-period it was born into and understood dependencies that were for specific versions of Python or specific environments.

> It's especially easy given that tests aren't part of the actual package and should only be included in source archives, not source distributions.

What's the difference between a "source archive" and a "source distribution"? I'm missing your point.

My goal is to be able to run the tests as part of the Gentoo Linux build script for this package. We skip this currently; otherwise I would have noticed the missing files sooner.

> What's the difference between a "source archive" and a "source distribution"? I'm missing your point.

One (a source archive) is literally the archive of the repository made by setuptools and uploaded to PyPI. The other (a source distribution) is meant to actually be installed by things Python tooling for an end user. One is meant as historical data, the other as an actual installable product (for lack of a better term). One can be downloaded by downstream redistributors and used to run tests, the other is meant to be downloaded and used by users.

> My goal is to be able to run the tests as part of the Gentoo Linux build script for this package. We skip this currently; otherwise I would have noticed the missing files sooner.

And that's an admirable goal. No one wants a downstream redistributor to package something incorrectly and only find out about it from users.

@sigmavirus24 I'm sympathetic to wanting the improvement from pipfile, but adding that feature will likely take longer than us just pinning sphinx. We can remove the pin when pipfile improves. Does that sound reasonable?

+1 to pinning

If we want to pin, let's pin. At the moment we're capping. I'm fine with pinning *temporarily*.

Closing and re-opening to trigger new builds with our fixed dependencies