WIP on locking refactoring

Do not use this commit.  It still has a lot of reimplementation,
refactoring, and test cleanup remaining to be done.  The new lock
class names are probably all going to change, too.
Refactoring ConsistentKeyLocker tests

I've reduced what was previously a couple dozen lines of boilerplate
EasyMock stubbing and setup into a set of five setup-helper methods
that model conceptual primitives in EasyMock, like
"recordSuccessfulLocalUnlock()", which internally records expectations
with EasyMock that the locker will make a timestamp call followed by a
call to the local lock mediator using that timestamp (order matters).

This is definitely cleaner from a design point of view.  However, I'm
not sure it's actually a practical improvement over copying
boilerplate.  It seems a lot harder to figure out what EasyMock
failures mean when the expectations involved in the failure are
scattered across a bunch of little helper methods.  Still
experimenting...
Locking refactoring WIP

In the middle of implementing-testing lock checking

This commit is part of a destructive refactoring effort.  Don't use
it.
Adding basic lock delete tests and impl

This is another refactoring commit.  The locking code is still
unstable and unusable in this commit.
Hooked up new locking code to legacy interface

Added some ugly glue code between the newly simplified locking
interface and the legacy graphdb ConsistentKeyLockStore/Transaction
interface.  Still needs some cleanup, and expected value slices won't
retry or gracefully handle errors.  In-memory and embedded Cassandra
lockkeycolumnvaluestoretest classes passed, but there are probably
still bugs at this stage.
Hacking ConsistentKeyLockStore/Txn

Fixes and kludges in equal measure around ConsistentKeyLockStore and
ConsistentKeyLockTransacton.  This commit focuses on the glue code
between BackendTransaction and the new locking implementation.
Expected values checking still needs refactoring.

* Made the new locking code consider only the earliest expected value
  for any give set of calls to acquireLock(key, column, expectedValue,
  tx) where only expectedValue changes and the other arguments are the
  same between calls

* Fixed ConsistentKeyLockStore using the same backing store for both
  data and locks
Hacked an Astyanax-Recipes-based lock impl

This is a proof-of-concept, but it would need cleanup in titan-core's
configuration of locking Backend.java, in the configuration of graphdb
tests using Astyanax, and also would benefit from a common abstract
base class providing functionality duplicated across
AstyanaxRecipeLocker and ConsistentKeyLocker.  I moved towards the
last point making LockState parameterized in the type of its
LockStatus class, but there is still work to be done on that point and
more on the other two.

The following three tests passed on my box with the new
AstyanaxRecipeLocker in use (but the class is otherwise totally
untested and should be presumed buggy):

* InternalAstyanaxGraphTest.java
* InternalAstyanaxGraphConcurrentTest.java
* InternalAstyanaxLockKeyColumnValueStoreTest.java
Fix ConsistentKeyLocker & Test

Moved ConsistentKeyLocker into appropriate test directory and tweaked
its test case to account for changing null argument lists in mutate()
to empty immutable lists.  Also commented some new logging lines in
the locker that were failing mock object behavior verification.  I
should probably just relax the constraints on the logging-related
method calls.
Refactoring new locking classes

Pushed LockerConfiguration classes and their builders into their
respective Lockers; created abstract base class and interfaces for
Locker code shared between AstyanaxRecipe and ConsistentKey impls
Locking refactoring and javadoc cleanup

* Moved AbstractLocker & AbstractLockStatus up from
  locking.consistentkey to just locking

* Added and rewrote javadoc on Locker.  It's now up-to-date with the
  current inerface semantics

* Updated ConsistentKeyLock* javadocs

* Deleted unused classes made obsolete by locking refactoring
Javadoc updates

Moved locking's package-level javadoc into ConsistentKeyLocker and
rewrote it
Javadoc and unused class cleanup
Moved LocalLockMediator classes

These classes are not ConsistentKeyLocker-specific, since they are now
used indirectly by both ConsistentKeyLocker and AstyanaxRecipeLocker.
I moved them from locking.consistentkey to locking, alongside the
AbstractLocker class that directly relies on them.
Javadoc fix in LockerState
Renamed ConsistentKeyLockStore/Transaction

These classes contain no actual locking logic.  That's delegated to a
Locker instance.  They are only responsible for expected value
verification at this point.  I renamed them to
ExpectedValueCheckingStore/Transaction.

This commit also adds another ConsistentKeyLockerTest method.
Fix Astyanax config regression

c209160ecacc5498475d98b717c29f1ba7ac1439 forced Astyanax's
NodeDiscoveryType and ConnectionPoolType settings to their respective
Astyanax-level defaults (not the defaults at the top of
AstyanaxStorageManager.java).  At issue was a builder method called
twice without coordination between the two calls.

This commit also removes the superfluous "storage" prefix on config
keys used in InternalAstyanaxKCVTest.
Merging titan03's Astyanax config fix
Reverse commons-config automatic list parsing

Rexster calls TitanGraphConfiguration#convertConfiguration with what
Apache Commons Config calls a "hierarchical" configuration.  This
subset of Commons Config automatically turns comma-separated string
values into lists.  TitanGraphConfiguration needs to join these lists
back together as Strings for e.g. passing a list of seeds to a
Cassandra backend.  RexsterTitanServer does not use hierarchical
configurations and is not exposed to this automatic list parsing.
Merge titan03's configuration-value list change
add HBase and LockKeyColumnValueStoreTest improvements