Real projects test: requests, popular Python package

This has already been added to real_projects, but I'm only getting around to analyze it now...

[x] Lots of self-imports: import requests, from requests.adapters import ..., from tests.testserver.server import ..., etc. exctract_imports should map out which modules/packages are available from the files that are being parsed, and skip/ignore these imports.
[x] Handle version-dependent conditional imports where some of the arms can refer to e.g. stdlib modules from very old Python version. E.g. in the following example (from requests's tests/conftest.py), FD will report BaseHTTPServer and SimpleHTTPServer as external imports, even though these were part of the stdlib before Python 3!:
```
try:
from http.server import HTTPServer, SimpleHTTPRequestHandler
except ImportError:
from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
```
Another case of this that uses StringIO/cStringIO can be found in tests/compat.py
[x] The setup.py does not pass literal data structures via install_requires and tests_require. Instead they indirect via simple lists. This is the first step on the ladder that starts with a fully static setup.py that we can already parse/interpret, and a fully dynamic setup.py that we cannot possibly make sense of unless we execute it (which is a security risk).
[x] There is a requirements-dev.txt file that we do not parse.
[ ] There is at least one example of a module that violates the identity mapping: setup.py mentions PySocks, which should be imported as socks. That said, I cannot actually find that it is imported by the requests code. This might be an actual unused dependency...
[ ] docs/requirements.txt lists sphinx as a declared dependency. This is never imported in the code, but is a tool that is run (e.g. via ./docs/Makefile) to generate documentation. FD reports this as an unused dependency, despite it clearly being part of the docs workflow in requests. This is an ecample of the general problem that not all dependencies are (meant to be) imported.

These are the issues I've found so far. There will probably be a couple more as we dig further.

tweag / FawltyDeps

Real projects test: requests, popular Python package #90