Refactor package structure

This change splits the `doss` and `doss.local` packages into four, in order to distinguish the classes and interfaces which are part of the public API. The new structure is:

* doss - client API
* doss.core - core interfaces and implementation details
* doss.local - local filesystem backend
* doss.sql - SQL database backend

Any interface that a client application is expected to use directly should be in the top-level `doss` package. Conversely anything a client application is not expected to use directly should be in a subpackage.

At some point we will start guaranteeing API stability for `doss` but not for the subpackages. Clients are expected to construct BlobStores using the convenience methods in `doss.DOSS` not directly. Admin tools are exempt from this guideline but must be prepared to suffer breakage due to implementation changes.