Delay global_connection and global_transaction initialization to latest possible moment

[rafalp]

This PR changes Database implementation so global connection is created only when its actually needed: when connection with backend is initialized. That way connection and its locks are initialized within same event loop, preventing issue documented in #157.

I've also had to change async_adapter implementation so it creates new event loop on every use instead of reusing already-existing event loop, which allowed me to reproduce error described in #157. It should also make tests run in env closer to "real" usage.

[lovelydinosaur]

Seems reasonable yup - what's the behavior of the test case without this change?

[rafalp]

@tomchristie if you were to merge only tests part of this PR, then test case would reproduce my initial issue, and tests would fail with RuntimeError: Task <Task pending coro=<Database.execute() running at /usr/local/lib/python3.7/site-packages/databases/core.py:122> cb=[gather.<locals>._done_callback() at /usr/local/lib/python3.7/asyncio/tasks.py:691]> got Future <Future pending> attached to a different loop error.

[lovelydinosaur]

Looks all v sensible to me.
I'll leave this for anyone else on the maintainance team to merge, then we should start looking at adding more PyPI permissions for releases.

[gvbgduh]

Looks safe to merge anyway!

But for future we can revise the async_adapter itself and async clients, I'm under impresion it's a bit more convenient to run everything within one event loop (or like one loop per worker/process), which is generally provided by pytest.mark.asyncio in tests.
There was some confusion with the starlette's test_client that creates the conflicting event loop. Also some confusion in scenarious, running databases independently or within the service driven by starlette.