Evaluate Python 3.5 compatibility of trezorlib

[matejcik]

Construct 2.10 has dropped Python 3.5 compatibility now, which causes some of our CI runners to fail the python test, which still tests Python 3.5.

We've been using 3.6 features in the test suite and elsewhere for quite some time now, but have been keeping 3.5 compatibility in trezorlib because it didn't cost us anything. That might be changing now.

We could fix Construct on version 2.9 and postpone the problem for a couple more months, but perhaps that is not worth it.

Debian stable version now has Python 3.7. We need to evaluate which systems could still be on 3.5 and whether it's worth keeping compatibility, or refering them to an older version of trezorlib.

If we decide to drop compatibility, the first (and the only required) step is dropping py35 target from tox config. An optional second step is using f-strings everywhere, and third step is variable type annotations.

[matejcik]

the problem that is breaking CI is actually a Construct packaging bug construct/construct#834
Hopefully this will be resolved on upstream side, so we will not need to pin the version.

after a review on Repology, it turns out that pretty much all relevant distros already have Python 3.6 or 3.7. But Debian Stretch (oldstable) still has 3.5, and this is presumably a rather large install base, so I'm choosing to stay on 3.5 as well for now.

Dropping priority and adding a "deferred" flag, I'm sure we will come back to this sooner or later :)

[matejcik]

#1266 breaks Py3.5 compatibility again: in def foo(*, a, b,) the trailing comma is a syntax error

we could resolve this if we want -- in any case, this issue must be resolved one way or the other before trezorlib 0.13 is released