Drop Python 3.4, 3.5, and 3.6 from tox/travis

[jeffwidman]

Reasons:

• 3.7 has been stable for over a year.
• this library is generally very stable. In other words, even if we do somehow break backwards compatibility we can tell folks to use an old version until they're ready to upgrade to 3.7...
• Anyone who is using python 3 probably isn't using their system python, ie, they are probably already installing a custom python version. So it should be relatively straightforward for them to bump that to 3.7. (I'm actually not aware of any linux distro's shipping python 3 as their system python other than Arch)
• This would drastically simplify our test matrix and given the relatively slow rate of change of this library it'd probably tide us over for another 3-5 years or so 😁

Thoughts @StephenSorriaux ?

[StephenSorriaux]

I also think it would be a good idea to drop some of the Python versions from our test suite. I was wondering if maybe we should keep the 3.6 version too because:

• it seemed widely used in the 2018 jetbrains report
• python 3.7 introduced the async and await keywords which breaks some libraries and, thinking of a project in general, that is not so easy to migrate from those 2 versions

[jeffwidman]

Sounds fine to me.

async/await are unlikely to creep into this project as we would need to shift all the internals to be asyncio to take advantage of that... more likely we'd start a second asyncio-compatible lib to do that.

3.6 introduces fstring formatting, that is the one that would likely break backwards compatibility with 3.4/3.5, but IMO that's not really a worry because again, most folks who are running python 3 in production are managing it outside of the system python so not hard to bump to 3.6 or 3.7.

[jeffwidman]

Fixed by #574