Upgrade setuptools to 36.5.0

[agronholm]

This allows projects to specify their metadata in setup.cfg instead of setup.py.

[ericholscher]

The Travis fail is invalid -- but have you tested this locally? I'm a little hesitent to futz with setuptools by itself, without the other related bits (virtualenv, pip, etc)

[agronholm]

Do you want me to upgrade the other tools as well?

[agjohnson]

@agronholm do you think there is any reason the current versions would be at odds with the new setuptools? we should be running more recent versions of each of the tools, but I'm not sure it makes a difference to us to upgrade in unison.

I'm playing around more with package configuration in setup.cfg in other projects, it's a rather nice alternative to setup.py 🙂

[agronholm]

No, I don't. If upgrading setuptools to the latest version had negative repercussions, all hell would've broken loose elsewhere. I've seen those situations with at least setuptools and requests.
On another note, I will update the PR to the latest setuptools.

[agronholm]

@ericholscher seems like Travis passes now, so do you still need me to run some checks locally?

[ericholscher]

Yea, travis is just code checks, this change will likely only effect actual builds, which is a hard thing to test in CI. This is another good use as @agjohnson mentioned for feature flags, would be nice to roll this out conditionally, and make sure it doesn't blow up on random environments.

[agjohnson]

#3171 bumps this again, will continue my work there.

I have a feature flag branch i'll be prepping for review today. We should be able to get this out with a basic feature flag so we're not indiscriminately forcing latest setuptools on projects. I'll follow up with a feature flag addition on #3171