Proposal to expose PgClient functionality through R2DBC API

[R2DBC](https://r2dbc.io) is an initiative to establish a common SPI for relational database drivers embracing reactive programming properties: Event-oriented, non-blocking, and ideally stream-oriented access to databases. R2DBC is built entirely on Reactive Streams defining a minimal API surface to be implemented by drivers without the need to re-implement common client functionality in every driver.

From an R2DBC perspective there are a couple of interfaces that could be implemented by using the following components of PgClient:

* `ConnectionFactory` -> `PgClient` and `PgPool`
* `Connection` -> `PgConnection`
* `Statement` -> Utility to build/prepare a statement, eventually calling `PgConnection.query(…)` or `PgConnection.preparedQuery(…)` methods
* `Result` -> `PgRowSet`
* `Row` -> (Pg) `Row`

## What is the benefit of doing so?

Benefits:

* Following an API that is well-suited for client developers without the need to entirely change how the client is supposed to work
* Participating in a growing client-ecosystem ([MyBatis](https://github.com/mybatis/mybatis-3/issues/1444), [draft](https://gist.github.com/kazuki43zoo), [JDBI](https://github.com/jdbi/jdbi/issues/1454), [Spring](https://github.com/spring-projects/spring-data-r2dbc)) with clients providing a humane API. Application developers get a choice of which client they want to use for specific use-cases.
* With the choice of clients, PgClient isn't required to provide additional functionality such as object mapping or SQL generation. That's up to the client.
* Choice of plug and play for a growing eco-system of drivers beyond [Postgres](https://github.com/reactiverse/reactive-pg-client) and [MySQL](https://github.com/mirromutth/r2dbc-mysql) (e.g. [H2](https://github.com/r2dbc/r2dbc-h2), Microsoft SQL Server) that can be used with vert.x.

Drawbacks:

* https://xkcd.com/927/
* Dependency on Reactive Streams (could be optional, still)
* Additional complexity by maintaining two driver frontends

Related ticket: #245.

Start by reviewing the existing PgClient, PgPool, PgConnection, PgRowSet, and Row APIs mentioned in the proposal, then compare them with the R2DBC ConnectionFactory, Connection, Statement, Result, and Row interfaces. The issue does not identify files, tests, or an agreed scope; a useful next step is to define the API surface and acceptance criteria before implementation.

Vom Indexierungsmodell aus dem Issue-Text verfasst.