What API expect from the Redis object?

I raised some concerns on Twitter about relying on the `redic` client, for a trivial _popularity_ argument, not anything else basically. @soveran proposed several solutions here: https://github.com/antirez/redimension/commit/37554bb7f564b44091b53bc735cb9e70706bee0d#commitcomment-14092099

I'm opening this issue to discuss, and to propose yet another solution among the options we have.

My idea is that we should abstract this away from a specific client, and just provide an object that is able to reply to some API that can be implemented as a wrapper on top of any other Redis Client.

However my feeling is that, for the popularity concerns I've, it's better if we model this API to be similar to redis-rb so that it works trivially in that case. So basically in my proposal the Redis object passed to Redis must be able to reply to the four commands used (should be four AFAIK), plus `#pipelined`, plus `#eval`. This way we may pass directly a `redis-rb` object, or may wrap a `redic` object into an object which proxies such an API. We can also provide directly the wrapper for different clients (basically `redic` since AFAIK there are no other popular enough clients).

Another solution would be to instead expect the Redis object we pass to Redis to respond to more `redic` alike APIs, and implement proxies for both libs for `redis-rb` (since anyway, there is no _natural_ way to handle pipelining or alike). Maybe this approach could be more sounding... because should be simpler to provide a proxy for `redis-rb` that already has internally a `connection` object that replies to raw commands.

The problem with all that is if also the replies reported by different client libs are different. Than the proxy must perform the transformation too, which may be slow.

Ideas?