Sleep after issuing DELETEs, not before

The other way around, list_keys might return keys that have already been asked
to be deleted, but who's deletion hasn't propagated to all the replicas yet,
making them show up in list_keys again.

The second DELETE for a key would also sometimes cause an exception due to a
missing vclock header in the response expected. This is a separate issue that
needs to be looked into.
Attempt to give Riak enough time to delete a key

Once it's gone from Riak, the 404 response returned won't include an
x-riak-vclock header, exposing a bug in constructing VClock results.
Deal with RemoveObject requests not providing a vclock
Fix the date of the last release
Version 1.3
Update README