Define a persistence API

[gterzian]

Currently a user could already persist documents and re-load them using a combination of:

1. The doc handle, which could be use to save the document and persists the resulting blob.
2. The Collection.load_existing_doc API, which takes a full document as argument, one that therefore could have been initialized with the blob persisted at 1.

We will have to define a higher-level API, one that could internally use incremental saves, and make it available to clients via a trait.

[gterzian]

First pass:

1. StorageAdapter is a Sink of StorageMessage, an enum with two variants:
   • SaveFullDoc(data)
   • SaveIncremental(data)
2. We add an API to automerge that returns the length of the changes(equivalent to get_changes_clock.unwrap().len())
3. After each change to a document(either a local edit, or applying a sync message), we call storage.poll_ready. When it becomes ready, we determine whether to do a full or incremental save based on a call to the api at 3(could be further configured, or even determined dynamically through a callback), and then start_send the appropriate message.

The idea is that if the sink is busy, then changes will pile up and the next message is likely to be a SaveFullDoc, whereas if the sink is not busy we'll do lots of incremental changes.

cc @orionz @alexjg

[gterzian]

Done in https://github.com/automerge/spanreed/pull/17