Fix race condition on fast updates

I found a race condition when an app is updating an object in fast succession. E.g. Litewrite is storing the document on every keystroke. When revisions are enabled (using a server implementing the 01-spec), on the second keystroke the update fails because the request is sent with an If-Non-Match header containing '*'. Since the document already exists, the server responds with a 412.

I tracked this down to a race condition in the IndexedDB node cache. When updating an object, the object is written to the node cache without a revision. The revision is only set when the server response comes in. But when a new update is already made before the server responded, the change that is created doesn't find a revision in the node cache, thus setting the If-None-Match header to '*' as if this was a completely new object.

The change of this pull request always sets a revision in the node cache when available. Either it's the revision given to the function as parameter (in case of an incoming server response) or the revision of the old node. The only case where it's set to `undefined` is when a new object is created.

I wasn't able to create a test for this yet, because

1. there are no existing tests for the IndexedDB cache yet
2. I haven't figured out how to test anything that involves IndexedDB with the existing test infrastructure

Any hints appreciated.