Revert tree state to 2285a80bbce1e919ac6398d7

This commit reverts everything from the head back to (but not
including) 2285a80bbce1e919ac6398d7adace41a2ac694a9.

I intend to follow this commit with cherry-picks of bugfixes and
optimizations from master (which received a merge from titan03 prior
to this commit).
Reapply bugfix/optimization changes

This commit is a combined cherry-pick of all stable-branch-worthy
commits on titan03 since May 14 (that is, after the commit
2285a80bbce1e919ac6398d7adace41a2ac694a9).  Commits introducing new
features or major refactorings are not included in here.  Here are the
commit hashes cherry-picked as part of this commit:

 fa5c1bffdf26f12b6f9c5330ea445c2d30b8a801
 1bea1e5a9d3de1b8eb128dd05c237b4a1d01201a
 b68ff656a16d69f315eea8bc3d7cbcf960598e74
 37b84fb6425485bd5f2ab0396885a9a9d616e47c
 162f942f4839b451fac706a2b0fa49f2eaf5ae77
 48c680b16582318630c56716b0ffc629177841db
 9257e39edf4132626b474629c6e3280e316dbeda
 e840704ae8e726f825a0aea09208d6ed7a3270fa
Adding new .gitignore pattern

This pattern omits pom.xml.versionBackup files created by the Maven
"versions:update-child-modules" goal.  The following page has more
information about this goal:

http://mojo.codehaus.org/versions-maven-plugin/update-child-modules-mojo.html
Update version to 0.3.2-SNAPSHOT
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.
Merging titan03 with strategy "ours"

titan03 contains four commits since its last merge into master.  The
first commit resets titan03 to a common ancestor commit of both
titan03 and master.  The next commit is a mass-cherry-pick containing
a subset of master's commits following the common ancestor (just
bugfixes and optimizations).  The third commit is a .gitignore change
that is already separately committed in master.  The fourth commit
changes the Titan version from 0.3.1 to 0.3.2-SNAPSHOT.  This change
is not in master and it should also never go into master.  Therefore,
the contents of all four titan03 commits are either already in master
(first three) or would be discarded during a merge (last one).

This merge has no effect on master's tree.
Merge branch 'titan03'

Merging #302's locking timestamp mismatch exception fixes and one
double-checked locking fix.