Require new-ish setuptools to build wheels

[Zac-HD]

Closes #1091. It looks like this actually works (at least in our CI)!

This PR also reorganises our input dependencies a bit, moving them to setup.py and adding minimum versions for most of them. I will probably move that to a separate pull as it's a bigger change than I expected - with the remaining piece to either fix or work around jazzband/pip-tools#204 (the -e .[...] line converted to local absolute path). Fortunately I think we can just strip lines starting with -e from our .txt outputs, so this is manageable.

[kxepal]

Shouldn't all requirements/* be dropped with this changes?

[kxepal]

Also, with new-ish setuptools you can move all the metadata to setup.cfg.

pyup bot got it support with latest release, so it should continue keep deps up-to-date. However, iirc, it couldn't manage setup.py itself.

[Zac-HD]

Shouldn't all requirements/* be dropped with this changes?

We still need something as inputs for pip-compile, and this would be a nice way to do it. Unfortunately it looks like the local -e .[dev] is expanded to an absolute file URL pointing at the local system, so I'll probably have to take this part of the change out 😢 (unless I can get it fixed upstream, of course).

[kxepal]

Why do we need pip-compile? It seems the work what it does could be solved by Pipfile.lock.

[Zac-HD]

pip-compile translates the unpinned top-level dependencies (from setup.py and requirements/*.in) into requirements/*.txt, which pin an exact version of every package in our dependency tree.

That fully pinned version means our CI builds are repeatable, including if we go back to an older version using now-outdated packages. This is also the target of our weekly updates from @pyup-bot, so we can see if our tests pass with new versions or fix things for upgraded linters.

[Zac-HD]

Closing this (and the issue) as wontfix - having done some more work, I just don't think correctness is worth the cost in compatibility with old versions at this time.