Test under PyPy3

`setup.py` and [`README.md`](https://github.com/psf/requests/blob/3c01cd708033295c65be3fd85dea9d453506c854/README.md#feature-support) explicitly list PyPy support. This PR extends testing to PyPy3 (which is currently Python 3.6-compatible). This will help ensure that support for PyPy3 does not regress.

PyPy3 build failure seems to be due to a stall?

```
============================= test session starts ==============================
platform linux -- Python 3.6.1[pypy-7.1.1-beta], pytest-3.10.1, py-1.8.0, pluggy-0.11.0
rootdir: /home/travis/build/psf/requests, inifile: pytest.ini
plugins: xdist-1.25.0, mock-1.10.4, httpbin-0.3.0, forked-1.0.2, cov-2.7.1
gw0 [559] / gw1 [559] / gw2 [559] / gw3 [559] / gw4 [559] / gw5 [559] / gw6 [559] / gw7 [559]
.....................
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
```

This could indicate an actual bug. If anyone knows the best way to enable some more verbose output, we could try that to see what is going on.

Edit: I've seen something similar before in another project where the cause was one of the dependencies that didn't support PyPy3. Perhaps something similar is happening here.

Hi @johnthagen, it looks like PyPy3 is unable to run our test suite on Travis right now due to timeout issues. It's not clear if this is an issue with Travis, or PyPy3 using Requests. I'm going to close this out for now, but if you're able to get this working please feel free to raise another PR. Thanks!

It's PyPy3, I have the same problem locally. I'm not sure if it's a problem with requests or pytest-httpbin though, since the latter also has hanging tests. It may be PyPy3's ssl implementation as well.

CC @mattip from the PyPy team. Is there a potential PyPy issue here?

How do I reproduce this? I activated a clean PyPy virtualenv, cloned the repo, and did
```
make init
make test-readme
```

The second command failed with
```
$ make test-readme
Courtesy Notice: Pipenv found itself running within a virtual environment, \
so it will automatically use that environment, instead of creating its own for \
any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to \
ignore that environment and create its own instead. You can set PIPENV_VERBOSITY=-1 \
to suppress this warning.
running check
error: The docutils package is needed.
Invalid markup in README.rst or HISTORY.rst!
```

It seems that `setup.py` is a bit broken. Edit it and change `pytest_args` to `'-vv'`. Then `pypy3 setup.py test` should give a reasonably verbose output to see where it hangs. For me, it's:

```
tests/test_lowlevel.py::test_use_proxy_from_environment[http_proxy-http]

~the problem is PyPy uses older logic for reading from a socket with no set timeout: if the other side closes the socket without writing anything it will hang (in `_socket.socket.recv_into`). I think this was changed on python3 to not hang. See [PyPy issue 3122](https://bitbucket.org/pypy/pypy/issues/3122)~

Edit: wrong - this is simply a resource leak

The real problem is that the `test_server/server.py` does not close the [socket returned from `accept`](https://github.com/psf/requests/blob/v2.22.0/tests/testserver/server.py#L92). On CPython, the socket is automatically closed when the function returns or raises since the variable is local. On PyPy the GC does not kick in, so the process hangs. Even worse, since this is in a thread, the resource leak is not reported.

This can be solved by using a context manager. Instead of the line I marked, use
```
with self._accept_connection() as sock:
```

and indent the subsequent block accordingly

Thank you very much for figuring this out.

@johnthagen, do you need me to make a PR for this or will you handle it from here?

@nateprewitt Could you please re-open this PR? Per the discussion, we have identified a bug in the test suite that once corrected, should allow PyPy3 to run tests successfully.

@mattip Can you confirm that this patch is what you were expecting for this fix?

- https://github.com/psf/requests/commit/18de73cd9a2fa84ec6ef272c7d4f1ba1a507b820

Pinging @nateprewitt to see if this PR can be reopened.

Pinging @sethmlarson, could this PR be opened? We've solved the issues related to PyPy3 testing.

Reopening to see if CI now passes.

@mattip Mind double checking my fix?

@mattip Nice, your suggestion fixed all of Python 3 / PyPy3 CI.

Now just 2.7 is failing: https://travis-ci.com/psf/requests/jobs/277906014

Seems like something about the Python 2.7 object isn't supporting context managers?

```
_______________ test_use_proxy_from_environment[all_proxy-http] ________________
[gw3] linux2 -- Python 2.7.15 /home/travis/virtualenv/python2.7.15/bin/python
httpbin = <function inner at 0x7f4fd1c33cf8>, var = 'all_proxy', scheme = 'http'
    @pytest.mark.parametrize("var,scheme", _proxy_combos)
    def test_use_proxy_from_environment(httpbin, var, scheme):
        url = "{}://httpbin.org".format(scheme)
        fake_proxy = Server()  # do nothing with the requests; just close the socket
        with fake_proxy as (host, port):
            proxy_url = "socks5://{}:{}".format(host, port)
            kwargs = {var: proxy_url}
            with override_environ(**kwargs):
                # fake proxy's lack of response will cause a ConnectionError
                with pytest.raises(requests.exceptions.ConnectionError):
                    requests.get(url)
    
            # the fake proxy received a request
>           assert len(fake_proxy.handler_results) == 1
E           assert 0 == 1
E            +  where 0 = len([])
E            +    where [] = <Server(Thread-1, stopped 139980796024576)>.handler_results
tests/test_lowlevel.py:203: AssertionError
----------------------------- Captured stderr call -----------------------------
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/opt/python/2.7.15/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/home/travis/build/psf/requests/tests/testserver/server.py", line 69, in run
    self._handle_requests()
  File "/home/travis/build/psf/requests/tests/testserver/server.py", line 92, in _handle_requests
    with self._accept_connection() as sock:
AttributeError: __exit__
```

yeah, a python2 socket.socket cannot be used as a context manager. You will have to go back to the original code and add a `try: ... finally: if sock: sock.close()`

@sethmlarson @mattip CI is now green across the board! 🎉 

This PR should be good to be merged now.