async support doesn't require patching

[davidism]

The patching is not required, async def is valid in all supported Python versions. Moves the async/patched sync functions from asyncsupport into the regular code. Moves the async filters from asyncfilters to filters. This does mess with the signature arguments in the docs for the filters, I think that can be fixed in Pallets-Sphinx-Theme's Jinja support.

import asyncio is done inside render and generate to avoid importing it at the top, which would slow down import time.

• fixes remove async patching system #1390

Checklist:

• Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• Add or update relevant docs, in the docs folder and in code.
• Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• Add .. versionchanged:: entries in any relevant code docs.
• Run pre-commit hooks and fix any issues.
• Run pytest and tox, no tests failed.

[davidism]

@pgjones related to #1191:

asyncio is imported in two methods on Environment, to call asyncio.get_event_loop() and loop.run_until_complete(coroutine). We can probably make those two separate, overridable methods on Environment in order to allow using Trio, etc.

[pgjones]

As I understand it the imports are in render and generate the sync versions of render_async and generate_async. In which case I don't think this is an issue (as trio.run(environment.render_async, ...) is valid).

I wonder though if these sync methods should instead raise runtime/not implemented errors in an async environment. I think this would happen naturally anyway as calling run_until_complete from within an event loop already raises a runtime error.