Fix double-checked locking in StandardVertex

Mark the field addedRelations in StandardVertex as volatile.  The
field is accessed using DCL in the addRelation(...) method.
Relax lock timestamp mismatch check

Writing a lock claim to storage may appear to fail on the client,
generating a StorageException, even though it actually succeeded.  For
example, a Cassandra cluster could complete a write but fail to
acknowledge it before triggering a TimeoutException.  These claims
linger in storage and pointlessly block lock aquisition by other
processes until aging past the lock expiration time.

This commit changes the lock verification step to accept a sequence of
claims sharing the same rid and differing only in their timestamps, so
long as the final timestamp matches that expected by the verifier.
This should alleviate one potential cause of timeout mismatch
exceptions as discussed in #302.
Stop caching lock column values

If writing a lock claim to a storage backend took longer than
LOCK_WAIT_MS to complete, then later attempts to verify that lock
claim would generate a guaranteed "timestamp mismtach"
PermanentLockingException.  This should now be fixed.

This was due to an interaction between
ConsistentKeyLockTransaction#writeBlindLockClaim(...) and
LockClaim#getLockCol(long ts, byte[] rid).  The former calls the
latter.  The latter calculated a return value only on its first
invocation, cached it, and then returned it on that and all subsequent
invocations.  It did this even if the ts argument, on which the return
value depended, varied between invocations.  In cases where a lock
claim write took longer than LOCK_WAIT_MS to succeed, this caching
behavior made retries write a stale timestamp and later caused a
"timestamp mismatch" exception.  This commit makes getLockCol(...)
calculate its return value on every invocation.

This should alleviate one potential cause of timeout mismatch
exceptions as discussed in #302.