Decide on Py35 support

[consideRatio]

In #368 I learned about working with the progress() function was problematic if you have py35 as it use yeild in an async function, but not really, because it use _yeild from the async_generator library. But, a lot of errors popped up in tests when using py35 specifically.

I'm not eager to fix that compatibility issue, what should we do? Document it? Require py36 when installing kubespawner? Letting kubespawner crash hard or provide a warning if using events with py35?

Here is some stuff to read about py35 and async for loops:

• https://quentin.pradet.me/blog/using-asynchronous-for-loops-in-python.html

[betatim]

I'd use this change to remove support for Python 3.5 and introduce a policy for how we decide which versions are supported.

https://devguide.python.org/#status-of-python-branches tells you which versions of Python the maintainers of Python support. 3.5 is now on;y accepting security fixes and will be EOL in September 2020.

I don't think we use v3.5 in any of the container images we produce so there shouldn't be anyone using it, hopefully.

For the mechanics I'd make it so that kubespawner doesn't even run/load with an unsupported version of Python. Otherwise people will get a semi working version with subtle bugs.

[consideRatio]

@betatim I added a removal-of-support-for-py35 commit to #368 as I understand that was what you suggested, which would be something I think also is fine.