Add partial support for detecting conflicting writes in VFS.write()

Support throwing an error from VFS.write() when writing an update
to an existing file based on a non-current version of the file.

This is work towards fixing a problem in onepass.Vault.saveItem()
where concurrent updates to the contents.js file can clobber each
other and result in items being lost from the index.

Add a 'revision' property to the result of VFS.stat() and
a 'parentRevision' property to a new options struct for VFS.write().
If the 'parentRevision' property is set in VFS.write() and does
not match the current revision of the file, the update fails
with a vfs.ConflictError.

In Dropbox, this maps to the API's mechanism for detecting conflicting
updates.

This system currently isn't completely reliable for the Node FS-based
VFS since the file mtime + size is used as a revision and the mtime only
has a resolution of 1 second in Node 0.10 and on OS X across all Node
versions.
Tidy up VFS tests

 * Use promise chaining to clean up code flow in promise tests
 * Fix an issue where localstorage VFS tests could fail
   if they executed quick enough that the same item was saved multiple
   times within a millisecond
Implement Map.forEach() in polyfill
Fix clobbering of contents.js updates by concurrent Item.save() calls

When multiple items are being saved in an Agile Keychain vault,
the updates to contents.js could clobber each other.

Fix this by only allowing one update of contents.js by a onepass.Vault
instance at a time.

When Item.save() is called, the update is enqueued and process to
write an updated contents.js file is scheduled. If Item.save() call
happens concurrently, it will either get picked up by the
already-scheduled update or another one which will happen when the
first completes.

When the keychain is stored in a remote VFS, eg. Dropbox, this also
reduces the number of API calls made to update the contents.js file.
Fix sporadic failure in VFS write conflict test

When performing the conflicting writes, if the write of the
string 'conflict-v2' happened first then the other write attempt
would not see a conflict because the (second-resolution mtime, file
size) tuple which make up the revision did not change.

Work around the problem by using different file contents of different
lengths for the initial write and the two conflicting writes.