Cleanup and fix filesystem.xml assembly

* Deleted two identical copies of the filesystem.xml assembly
  descriptor.  Instead of having separate copies,
  titan-dist-hadoop-{1,2} now share a single one that lives in their
  common parent.

* Made -Ddev.hadoop=2 the default again.  Just prior to this commit,
  neither the hadoop1 nor 2 version of the filesystem.xml assembly
  activated by default, so no (reporoot)/bin, lib, conf,
  ... directories would be created by default.  We've been building
  these directories by default for a while, so that behavior has been
  restored.
Add test of HadoopConfiguration

This commit extends WritableConfigurationTest with three datatypes
currently used in practice but not currently tested: enums, durations,
and Object.class.  The new duration test coverage augments existing
string-duration-parsing coverage in CommonConfigTest.
WritableConfigurationTest is the base class from which the new
HadoopConfigurationTest inherits, as do the existing
KCVSConfigurationTest and CommonConfigTest classes.

This new test covers a bug in HadoopConfiguration that prevented it
from setting or getting keys with datatype Object.class.  It fails
right now.  AbstractConfiguration.getSubset requires that
WriteConfiguration impls accept Object.class.
Relax WritableConfigurationTest Object.class case

Allow WriteConfiguration implementations to return anything that is a
subtype of Object instead of something that has the exact type Object
(i.e. anything that's not a primitive or array).
Fix HadoopConfiguration's Object.class handling

It now supports get/set with datatype set to Object.class.  Sets are
serialized by toString() and gets return that String.
Remove List-valued ConfigOption support

The only List-typed ConfigOption appears to be in
AbstractCassandraStoreManager.  That use can be served equally well by
a String[].  I converted it to ConfigOption<String[]> and removed
support for List-valued types in CommonsConfiguration.

List-valued types are problematic in the ConfigOption API since we
can't check the erased type of their generic parameter at runtime.
Fix #722
Rudimentary deprecation support in ConfigOption

This commit doesn't change the way ConfigOptions are read or written
to account for deprecation.  That's still the responsibility of client
code.  I didn't want to further complicate the config subsystem with
that, at least not yet.

This commit does add a new constructor that accepts a "deprecatedBy"
option of type ConfigOption, indicating that the option under
construction is deprecated in favor of the arrgument.
ConfigurationPrinter checks for this and formats deprecated options
differently; it draws their names with strikethrough and prepends a
red "Deprecated by..." warning to the struckthrough name.  Necessary
CSS and docbook tweaks also included in this commit.

This could be theoretically be extended so that BasicConfiguration
(and others?) are aware of deprecation and will favor the successor
option when it is set automatically, or to issue warnings.  I don't
want to tackle those quite yet.  Warnings are also harder than they
sound, since we don't want to constantly spam the log with them if a
certain piece of Titan repeatedly reads a deprecated option from its
config.
Deprecate edge-copy-dir for -direction

Per #718
Option-ify Faunus's Kryo output buffer size

titan.hadoop.serializer.max-output-buffer-size now controls the
maxBufferSize parameter passed to com.esotericsoftware.kryo.io.Output
objects instantiated by Titan-Hadoop.  This is a hard upper-limit on
the size of serialized representations of objects written by
Titan-Hadoop.  It defaults to the same value which was hardcoded prior
to this commit, 10 MiB.
Refactor Faunus edge copy config handling

Reducing some duplication in how deprecation of edge-copy-dir in favor
of edge-copy-direction is handled.  Still short of a general
mechanism, just slightly cleaner than before.
Prefer Titan's Configuration to Hadoop's in Faunus

This commit:

* Replaces uses of Hadoop's Configuration object with a Titan
  ModifiableHadoopConfiguration that supports the ConfigOption API in
  many classes

* ConfigOption-ifies several internal Faunus config options which are
  not user-facing but which nonetheless share the Hadoop Configuration
  during MR task execution and should hence be part of Faunus's
  ConfigOption tree

* Optimizes ModifiableHadoopConfiguration to cache the values of
  track-paths and track-state.  These options are read hundreds of
  times a second in some workloads as FaunusVertex objects get
  deserialized by Hadoop and fed into a mapper/reducer, and each of
  those invocations calls Configuration.get on the track-paths and
  track-state options.  The Hadoop Configuration backing that request
  does (uncontended) synchronization in its getProps method; the
  overhead of these repeated synchronizations in EdgeCopyMapReduce is
  enough to make its reducer run many times slower than necessary.
  Now these values are cached to avoid uncontended synchronization
  inside Hadoop's Configuration object when checking state/path
  tracking.
Lazily initialize BasicConfiguration.isFrozen

This is another Faunus-specific config performance tweak intended to
work around synchronization costs in Hadoop's Configuration
implementation.

BasicConfiguration's constructor looked up the hidden.frozen key in
its backing store during construction.  When the backing store is an
org.apache.hadoop.conf.Configuration, this incurs at least uncontended
synchronization.  This commit delays the cost of that synchronization
by lazily initializing the frozen class field the first time it is
read.
Remove daemon-killing shutdown hooks in testing

the killAndUnregisterHook method modified in this commit didn't
actually unregister the hook.  Fixed.
Introduce alternative ES configuration options

Setting the new index.[X].elasticsearch.interface=NODE or
TRANSPORT_CLIENT option enables completely new Elasticsearch client
configuration and initialization logic.  Leaving this interface option
unspecified (the default) keeps the old config options and their
interpretations.

The new initialization logic highlights:

* Can include an elasticsearch configuration file with arbitrary ES
  settings, regardless of whether using TransportClient or Node

* Can set arbitrary ES settings inside the Titan config by using the
  index.[X].elasticsearch.ext. prefix,
  e.g. index.[X].elasticsearch.ext.node.data=false

* Can use Node with either network or local transport; no longer stuck
  with just local transport as under the old configuration system

This commit also adds a rudimentary test of the new configuration
system in a new test class.
Add test of ES conf-file option

Test current fails by triggering #720
Fix #720
Cleanup Closeable handling in ElasticSearchSetup
Rewrite Elasticsearch AsciiDoc chapter

Reorganized and expanded to cover the new
index.search.interface=... configuration approach to ES alongside the
old legacy ES configuration settings
Tweak AsciiDoc admonition block styles
Tweak ES INDEX_DIRECTORY handling, config tests

ES now just checks whether the config has an explicit value for
INDEX_DIRECTORY instead of checking whether any of the path.data,
path.work, and path.logs settings are present.

Adding some new test cases to exercise Elasticsearch data/work/logs
directory configuration behavior described in the docs.