add 'mapr-m7' profile to titan-hbase pom file, to support MapR Tables as Titan backend
add note about MapR Tables as Titan backend
better assurance of CF existence.  modifyTable is flaky, addColumn/deleteColumn is more reliable.
Splitting HBase into modules for 0.94 and 0.96

This commit compiles and passes tests against HBase 0.94.16 + Hadoop
1.0.4 and against HBase 0.96.1.1-hadoop2 + Hadoop 2.2.0.

Several things still need work: titan-dist's dependency on titan-hbase
is no longer complete and effective since that's just a pom, some of
the hadoop dependencies need to be made optional and/or provided/test
scoped, probably some other stuff...
Adding HBase 0.96 adapter to titan-dist
Mark hadoop-core optional for HBase 0.94.x

Marking both the hbase and hadoop-core dependencies as optional to
make users redeclare the dependencies with their chosen
distribution/version.
Change localhost to 127.0.0.1 in cassandra.yaml

Makes Cassandra likelier to start on machines with a broken resolver
configuration.
Testing HBase 0.96 hadoop1/2 support

HBase 0.96 + hadoop1 is possibly broken pending
https://issues.apache.org/jira/browse/HBASE-10494

HBase 0.96 + hadoop2 compiles and tests against Hadoop 2.2.0.  This is
the default build configuration of the titan-hbase-096 module.
Disable HBase version defaults check in testing
Add HBase compression algorithm option

Closes #584
Cleanup HBaseStoreManager imports and generics
Add Netty dependency to HBase 0.96-hadoop1

Fixes a ClassNotFoundException during HBase minicluster startup in
testing of the HBase 0.96 + hadoop1 build
Update HBase shell scripts for 0.96

I initiall copied over 0.94's shell scripts to the 0.96 test
environment, but there have been a lot of changes between 0.94 ->
0.96, so I pulled the scripts in 0.96.1.1-hadoop1's tarball
distribution.  I patched bin/hbase's classpath cache logic to be
compatible with our maven build environment.  A bin/hbase patch is
included in this commit as a convenience.
Make LZ4 Cassandra's default compressor

Fixes #487

Also modified the compression settings test to use the compression
ConfigOption's default value instead of hardcoding Snappy as the
assumed default.
Refactor ID Partitioning configuration

Instead of a boolean, ID partitioning is now a three-valued enum:

* DEFAULT
* ENABLED
* DISABLED

ENABLED corresponds to the old value of true, and DISABLED corresponds
to the old value of false.  DEFAULT is the new behavior.  This enables
partitioning if the backend store reports isKeyOrdered() &&
isDistributed() via its StoreFeatures.  Otherwise partitioning is
disabled.

A warning is logged if the user sets DISABLED but the DEFAULT feature
criteria are true.
Break some &&'d Preconditions into multiple calls

Precondition boolean expressions with && conjunctions are ambiguous
without a detailed error message, since it's not possibe to tell which
clauses were false.  I separated a few instances of this around ID
partitioning handling into multiple Preconditions calls for the same
correctness guarantees but with less ambiguity and slightly increased
overhead cost.
Rewrite HBase's getLocalKeyPartition

This theoretically does the necessary length padding and endKey binary
arithmetic necessary to convert from HBase's startkey/endkey
convention to Titan ID partitioning conventions, but it is almost
totally untested.
Handle zero upper partition bounds

VertexIDAssigner reads the first four bytes of key ranges provided by
getLocalKeyPartition as ints.  It then unsigned right shifts the ints
by two bits each to make them effectively 30 bits wide.  It does some
arithmetic on the ints to preserve inclusive-start and exclusive-end
semantics and then passes them to PartitionIDRange's constructor.

Here's the computation done on each range-end int:

  partition[1] = (partition[1] >>> 2) - 1;

If the original partition[1] value is 0, this results in
Integer.MIN_VALUE.  Because the partition width is 30 bits, this value
is invalid (too wide since the MSB is set).  This value leads to a
precondition failure shortly after in PartitionIDRange's constructor.

I think the intent is to follow the subtraction by zeroing the two
most significant bits, simulating 30-bit wide unsigned integer
arithmetic and allowing underflow.  So this commit adds a bitmask
after subtraction like so:

  partition[1] = (partition[1] >>> 2) - 1;
  partition[1] &= 0x3FFFFFFF;
Fix bogus HBaseGraphMetrics test failure

When I enabled ID partitioning by default on HBase, it switched from
initializing a single ID pool to 10, the default value of
SimpleBulkPlacementStrategy.CONCURRENT_PARTITIONS.  This caused
HBaseGraphMetricsTest#testKCVSAccess1 to fail when counting the number
of getSlice calls made by a graphdb instance, since initializing those
extra pools requires more getSlices.
Adding a debug log message in VertexIDAssigner