Add built in query cache

[karlseguin]

I was talking with @fishcakez in elixir's slack and lamenting the difficulty in making use of Prepared statements when not using Ecto. It would be nice if DBConnection provided some of the facilities and part of the implementation to make this work across drives.

I think it's a common case that people want to prepare statements on startup and then execute those statements at runtime. We've handled this internally be having a macro register the name + sql, on startup, preparing the sql and storing the query into ETS. We can then execute a query by name which pulls the query from ETS.

I could see people struggling with setting this up. A part of the challenge is defining the prepared statement but deferring the actual preparation until the DB is up (and what if you have multiple databases, you need a way to specify which one you mean).

[fishcakez]

We wouldn't be able to use this feature in Ecto, without it becoming quite complex. Therefore it would need to be done outside DBConnection :(.

[fishcakez]

I think we can provide this feature if we solve another issue (#123). To decouple caching decisions (not cache features) from Ecto we require a protocol for errors that determines what to do with the cached queries on error. I think we can make it part of the existing query protocol. The reason we need a protocol is that each adapter can get database errors (e.g. Postgrex.Error) that hint we should reset the cache.

[josevalim]

I believe the latest changes make this more trivial to implement but the issue is that Postgrex.execute/4 does not return the reprepared query. Maybe we should actually normalize DBConnection.execute/4 to always return {:ok, query, result} and update the return results of Mariaex and Postgrex too? This way we can also stop accessing DBConnection directly from Ecto adapters.

[josevalim]

Most of the work here is done. The next step is to normalize the execute return types, as seen in #147, and then change Postgrex and Mariaex to always return it.