Support configurable HBase timestamp resolution

* the HBase diskstorage code now uses transaction-provided timestamps

* ConsistentKeyIDManager has gone back to using the value of
  GraphDatabaseConfiguration.TIMESTAMP_PROVIDER on the graph config,
  instead of using milliseconds everywhere, due to the next change...

* HBase's clearStorage() method now looks at the first row and column
  returned by its scanner and guesses the timestamp resolution based
  on magnitude.  This means clearStorage() will not work with
  arbitrary user-supplied timestamps, but only with millisecond,
  microsecond, or nanosecond timestamps based on UNIX Epoch.  I would
  prefer to use HBase's recommended truncation method of disabling the
  table, deleting it, and recreating it, but when I tried it, that
  roughly quadrupled the runtime of the test suite.

* eliminated some unused methods from HBaseKCVS

* removed the sleep following writes in HBaseStoreManager's
  mutateMany method

* added explicit timestamp bounds to HBase read command objects
Adding sleep after mutate back into HBase

Though this probably isn't necessary on a large deployment where the
HBase endpoint is on a machine physically separate from the Titan
machine, I just got an error in pseudocluster mode testing where
everything is local.  Not worth introducing a race to save one
millisecond per mutate.
Add general sleep-after-mutate method

HBase already slept after mutating, but now instead of sleeping for a
hardcoded millisecond it sleeps for a time based on its
TimestampProvider (but falls back to 1 ms if no provider is set).

Cassandra could get away without this method in its mutate
implementations back when it used nanotime, but with millisecond
resolution (Timestamps.MILLI or .MICRO providers), some of the tests
routinely fail because multiple operations are colliding inside a
single millisecond (MultiWrite especially).
Fix bug in Timestamps.MICRO.sleepUntil
Expose ID renewal exceptions to client

Exceptions in the ID renewer ("IDBlockThread") which previously were
invisible to the Titan client, appearing only as uncaught exceptions
on stderr, are now passed up to the client using Future.get().

closes #527
Shutdown executor in StandardIDPool.close()
Make IDPoolTest parallel

IDPoolTest creates an array of Threads.  It then iterates over the
array, first calling run (not start), and the iterates a second time
calling join.

Because the context contains joins on all these threads, I suspect
calling run was a mistake and start was intended.  I've modified the
line in question.
Fix minor concurrency bug in IDPoolTest

Now that IDPoolTest threads actually run in parallel instead of
serially (78b9a0af2e60db3ae841ccbfafe2393d0b56f030), they've run
across a problem in MockIDAuthority.  Its getIDBlock method is
instance-synchronized, but it needs to be concurrently accessed by
multiple threads.  When delayAcquisitionMS is nonzero, this can result
in unlucky threads waiting 2 or 3 times the delayAcquistionMS period
and the enclosing test throwing an unexpected exception.

I tweaked MockIDAuthority's constructors to make the
delayAcquisitionMS variable final, squinted at the getIDBlock
implementation for a while looking for anything else thread-unsafe
(found nothing), and then removed the synchronized modifier.
Logging and thread name tweaks in StandardIDPool