[DO NOT MERGE] Drop py35

[grigi]

The plan is to have this as the next master base. I'm leaving this here as a PR so its easier to manage.

DONE:

• Drop Py3.5 support
• Remove py3.5 "hacks" in tests/examples.
• Upgrade to f-strings (used flynt and pyupgrade to help automate)
• Use variable annotations
• Update docs re py3.6 now being minimal supported version.
• See if it is beneficial to use async generators/comprehensions in core code
• OptimizeModel._init_from_db to minimize calling to_python_value if we have guarantees that allow for it to be skipped.

[coveralls]

Pull Request Test Coverage Report for Build 797

• 261 of 266 (98.12%) changed or added relevant lines in 23 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 98.263%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
tortoise/models.py	70	72	97.22%
tortoise/queryset.py	41	44	93.18%

Totals
Change from base Build 793:	0.2%
Covered Lines:	2858
Relevant Lines:	2886

---

💛 - Coveralls

[grigi]

@abondar This PR has two basic things:

1. Changed to Py3.6+ syntax & features. This should actually reduce the line count noticeably.
2. Added a lot of tests, and fixed a few minor bugs.

I am going to split this up into the tests & bugfixes (backport for 0.13.6).
Then rebase this to ONLY do the py3.6+ conversion.

But please have a look at this PR :-)

[abondar]

Looks all good to me
Am I right that speedup was achieved by implementing all things around native fields?

[grigi]

Yes, the speedup was mainly on two "special" cases:

1. Native fields, as in types supported natively by the DB/connector/Python, requires no conversion.
2. When we use the default to_python converter, implement the code in a loop instead of calling the method. In my profiling I found that the method call was quite high, as it did virtual table lookups, and all that the default to_python method was was to «cast» or None which was a lot less than the mthod call overhead.

This gave a better speedup with larger models with more fields.

We could probably do a similar speedup for creating from Python via the constructor, and the converting to the DB fields. But we are running out of Python-level inefficiencies to optimize. We'll soon have to expand the benchmarking system to test DB/connector/Tortoise interactions. e.g. Are we using the indexes correctly? Is there any unnecessary overhead with the DB connectors for MySQL/PostgreSQL? Do we set up the DB fields correctly for case-insensitive operations? etc...