`edgedb` crate structure

We has always wanted to expose bindings under edgedb crate instead of the edgedb-tokio/whatever. But the structure of that is not very clear. Here is a sketch of my current thinking.

1. Expose edgedb::model, edgedb::error, and whatever is needed for derive macros.
2. Feature tokio: exposes edgedb::tokio
3. Feature blocking: exposes edgedb::blocking (which probably a blocking wrapper around tokio)
4. We might have default-tokio and default-blocking client which expose respective clients to the top-level namespace edgedb::tokio::Client -> edgedb::client, edgedb::blocking::Client -> edgedb::Client.
5. Potentically async-std/glommio or whatever new runtime can be done via it's own crate and brought here via feature flag. Also blocking implementation that doesn't depend on tokio could be implemented in the future too.

Ideally when async traits arrive to the stable Rust here is how it should work:

1. There is an edgedb-async crate which contains traits for executing queries
2. Libraries (which are not end-user apps) depend on edgedb-model and edgedb-async, but not edgedb crate (it's unclear how that would work with edgedb-derive, though).
3. When we bump major version of edgedb only app could be updated
4. When we bump major version of edgedb-model and edgedb-async we do adapters that allow libraries using older versions to work (i.e. transform to new types, see log crate for an inspiration)

But I'm not sure whether this is practical enough, and/or when this will become practical.

Start by mapping the existing edgedb, edgedb-tokio, and related crates, including their public modules and feature flags. Compare the current structure with the proposed edgedb::model, edgedb::error, edgedb::tokio, and edgedb::blocking namespaces. Done requires an agreed crate and feature architecture, not just an isolated code edit.