Wrap QueryExecutor implementations with Metrics

This times and counts (invocations and exceptions counted separately)
calls to the methods on implementations of the QueryExecutor
interface, when the calling transaction has metrics enabled.  Any
transaction-specific metrics prefix, if configured, is honored.  Time
spent in iterators returned by methods on the QueryExecutor interface
are *not* covered by these metrics.  This is part of #402.
Reformat broken debug log message

Fixes #544
Add Metrics counters on locking operations

Metrics counters added for calls to and exceptions in the write,
check, and delete lock methods of AbstractLocker.  ConsistentKeyLocker
extends AbstractLocker.  A transaction-specific metrics name prefix is
honored when set.
Rename ExpirationStoreCache metrics

When I originally added Metrics counters to this class, I mistakenly
set the counter names to just "ExpirationStoreCache".  Now the names
start with GraphDatabaseConfiguration.METRICS_SYSTEM_PREFIX_DEFAULT +
"." + "ExpirationStoreCache".  In other words, the metrics in here now
start with "com.thinkaurelius.titan.sys.ExpirationStoreCache".
Tweak getSlice and getKeys metrics names

* prevent getSlice from attempting to log metrics with an empty-string
  name prefix when metrics are disabled

* rename com.thinkaurelius.titan.getKeys.iterator.* to
  com.thinkaurelius.titan.stores.getKeys.iterator.* to conform with
  the naming pattern of every other storage metric
Update ConsistentKeyLockerTest for Metrics changes

ConsistentKeyLockerTest is, by design, extremely sensitive to
internals changes in ConsistentKeyLocker or AbstractLocker.  The test
started failing when I added calls to
tx.getConfiguration().getMetricsPrefix() in AbstractLocker.  In this
commit, I changed ConsistentKeyLocker to allow any number of calls to
tx.getConfiguration().  The configuration doesn't hold mutable lock
state, and this is the second time I've stumbled over spurious
tx.getConfiguration() failures in ConsistentKeyLockerTest, so I think
relaxing this constraint is appropriate.
Refactor metrics configuration handling

Previous to this commit, GraphDatabaseConfiguration used
metrics.enable-basic-metrics while Backend used
storage.enable-basic-metrics.  There's no good reason for these
options to be separate.  It's just confusing.

The config option wording is also clumsy.  In retrospect, it should
really have been metrics.enabled.  Titan's Metrics support and
metrics.* config namespace grew out of the storage backend, but now
Metrics covers other stuff in Titan besides storage.

To support existing configs, I made GraphDatabaseConfiguration and
Backend both consider metrics globally enabled when any one (or more)
of the following config options are set to true:

* storage.enable-basic-metrics
* metrics.enable-basic-metrics
* metrics.enabled

Storage backend metrics are merged when of the following are true
(they are each true by default):

* metrics.merge-basic-metrics
* storage.merge-basic-metrics
Change System.err.println to log.debug