Split out client library

[3noch]

I doubt this is a high priority, but eventually it would be nice to avoid Project:M36's massive dependency tree by pulling the client API out into a separate library. If the split allowed the library to only support remote connections, then it could be even lighter. An library that only supports in-process connection would also be nice and could shed a number of dependencies as well.

[agentm]

I have mulled over this, too, but this could get complicated because we would need to break out a separate remote client library. The current ProjectM36.Client provides identical interfaces for local and remote databases, but I could certainly imagine identical APIs for ProjectM36.Client.Local and ProjectM36.Client.Remote. This could be further complicated when we start introducing client-side features (which I have not yet fleshed out) such as tuple sorting or caching. I do like the notion of being able to use a fully-featured local database to cache parts of a remote database, but I certainly understand the lightweight client-side expectations when compared to other databases.

Currently, the only workaround is to use the websocket interface which is the lightweight interface.

[jmatsushita]

Seems that this would be really useful! Could it for instance allow project-m36-typed to only depend on a project-m36-client package? And:

use a fully-featured local database to cache parts of a remote database

Is this somewhat related to isomorphic schemas and #223 if these local caches where updatable? Certainly expands the scope of what a client is. I really like the sound of it!