Remove unused field
Make ReflectiveConfigOptionLoader more robust

Related: https://groups.google.com/forum/#!topic/aureliusgraphs/FD5cKy72h7Y

ReflectiveConfigOptionLoader walks the classpath at startup, looking
for static ConfigOption fields to initialize.  titan-all depends on
titan-hbase, but it leaves declaration of an hbase-client dependency
to the user.  titan-hbase's classes won't actually link without an
hbase-client jar available.  If the user doesn't provide one, then
ReflectiveConfigOptionLoader will walk over HBaseStoreManager's
ConfigOption fields and die with linkage errors on org.apache.hbase
when trying to load HBaseStoreManager and initialize its fields.

ReflectiveConfigOptionLoader now catches and warns on linkage errors
it encounters while walking the classpath instead of propagating them
up the stack.

titan-all still needs to depend on hbase-client.  Right now,
declaration of a dependency on hbase-client is left up to the user;
this is too brittle.  Better to set a dependency on some version than
none at all, leading to classpath problems if the user doesn't declare
an HBase dep.  That will happen in a follow-up commit.
Fix titan-all dependency problems

This commit makes two changes in titan-all's dependency tree:

1. titan-all now depends on hbase-client 0.98.2-hadoop2.  Before, it
   didn't depend on an hbase/hbase-client version, relying on the user
   to set one or exclude the titan-hbase module in their own pom.
   titan-all now sets a default version to avoid
   NoClassDefFoundErrors.  Downstream poms can override or exclude it
   as desired.

2. titan-all now explicitly declares dependencies on the Jackson 1.x
   and 2.y artifacts that it indirectly uses.  titan-all doesn't
   directly use Jackson, but its transitive deps do.  Furthermore,
   those transitive deps brought in a combination of 1.8 and 1.9 jars,
   and this led to NoClassDefFoundErrors at runtime.  Now titan-all
   sets all the affected artifacts to the same version declared in
   dependencyManagement.

   Importing dependencyManagement might be the cleaner approach:

   http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies

   However, I'm wary of imposing additional requirements on downstream
   poms that want to use titan-all.  Also, I don't know whether
   dependencyManagement imports work on non-Maven tools that parse
   poms, such as gradle or sbt.  The approach in this commit is
   stupider than dependencyManagement imports but also simpler and
   should work regardless of the tool manipulating the downstream pom.