Improve observable API

[ept]

In #308 we introduced an experimental "observable" API allowing applications to register callbacks that get called whenever an Automerge document (or a particular object within it) changes. At the moment, this API is not very friendly, since it simply exposes the patch format (as used by the frontend-backend protocol) to the application.

I'm opening this issue as a place to collect ideas for improving the Automerge.Observable API in future releases. Some initial ideas:

• If you want to register a callback on an object that is not the root of a document, you can only do that after the object exists in the document. Thus, you cannot register the observer immediately on Automerge.init(), but you have to wait until the changes that create the initial document structures have been applied before you can register the observer. That can be quite inconvenient. Maybe we should allow registering an observer at a particular path (e.g. JsonPath), even before an object exists at that path?
• The deeply nested JSON structure of patches, containing various opIds and hashes and stuff, is necessary for frontend-backend communication, but make for an unfriendly API. Maybe the observable API should focus more on making the common case easy (where there are no conflicts, where we update only one object at a time, …) rather than incurring all the costs of full generality.

The Observable API is currently marked as experimental, so we can make breaking changes to it without a major version bump.

[ept]

Another idea:

• When observing a nested object somewhere inside the document tree, provide the observer callback with the JsonPath from the root to that object for which the callback is being called (Pass a path to the observed object to observable callback #315).