A plan for version 0.1

[tailhook]

Since we have first pool API implemented in #88 we can have some plan for 0.1 which is nowhere near feature-complete, but can be used to play with API a little bit.

The plan is:

1. Experiment with executor trait. Notes:
   1. We can't make current query<Arg, Res>-like methods on dynamic value, because they aren't object-safe. The idea is to make less ergonomic methods (e.g. generic_query(dyn Arguments) -> dyn ResultDecoder) on the trait Executor itself and then ergonomic methods on dyn Executor. Or make some wrapper type. Not sure it will be ergonomic enough. If it will not work we can proceed with either non-object safe Executor trait or with API tied to a Pool object and this stage.
   2. We probably want &mut self on trait methods (they are &self on Pool). So that Transaction object can implement the trait too. This means actual pool object needs to be cloned for parallel tasks. Clones are cheap. And this will probably be the case anyway (to put pool object to the task state). And transaction will do the borrow, which is a good idea too.
2. Hide all fine-grained CLI API under unstable flag
3. Make sure that everything needed from underlying crates are re-exported from the edgedb_client.
4. Make sure that generated docs cover all essential use cases and all public things (warn(missing_docs))
5. Rename Pool -> Client

The limitations of this release are:

1. async-std-only
2. No transactions
3. No retries
4. No manually acquired connections, so CONFIG SET and START TRANSACTION and similar aren't possible too
5. Maybe some limitations on supported argument and result types

Previous discussion on #32

[tailhook]

Actually released as 0.2.0