Make Faunus pkeys Cardinality.LIST by default

These were Cardinality.SINGLE by default before, which maps to
Multiplicity.MANY2ONE and could lead to bizarre schema enforcement
failures even in workloads that had no explicit schema (such as
reading N-Triples and writing SequenceFiles).  These keys are now
LIST/MULTI by default.
Revert "Make Faunus pkeys Cardinality.LIST by default"

This reverts commit 70af3f9b5cf9b2811f3aa33aadfec4b51d5aca07.

The reverted commit caused a plethora of test failures, all variations
on an expected value X in a test method mismatched against the actual
value of a-list-containing-X.
Disable Faunus type checks when guessing schema

FaunusElement does some cardinality/multiplicity integrity checks when
adding relations.  These are not meaningful when the
cardinality/multiplicity of a type is unspecified, such as when
reading from N-Triples and writing to SequenceFiles.

This commit disables the checks by default.  They can be reenabled
when writing to a Titan output format, though the checks are not a
complete data integrity guarantee when batch-loading is enabled.  In
particular, it's still possible to violate a uniqueness constraint on
a property key when batch-loading is enabled and the Titan-Hadoop
schema checks are enabled.
ThreadLocal cleanup

This commit removes ThreadLocal usage from KryoSerializer and
CTConnectionFactory.  The KryoSerializer ThreadLocal caused problems
with Tomcat (#877).  CTConnectionFactory's ThreadLocal seems to
produce a unmeasurably-small performance gain, if it produces one at
all, so I replaced it with an ordinary private final field.
Remove unused field in KryoSerializer

c4c72ab3d978f5a5a8515365ecc429fe70215b02 appears to have removed the
last use of KryoSerializer's private 'registrations' field.  It's not
used as of this commit.
add cfg opt for sleep time after ES index creation

The Elasticsearch adapter had a hardcoded 200 ms sleep after creating
an index.  This is now configurable through
index.[X].elasticsearch.index-creation-sleep.  The default remains
unchanged (200 ms).
Add ES replica/shard count options

This allows the Titan configuration to supply arbitrary key-value
settings passed to the Elasticsearch cluster when creating an index
during DB bootstrap.  This commit reuses the configuration handling
code introduced in 304f14e44f986e806ac8e86437ff7b8e46a68045, except
this commit controls index creation settings, whereas that prior
commit controls client settings.

This commit introduces two new config elements:

* index.[X].elasticsearch.create.ext (namespace)
* index.[X].elasticsearch.create.conf-file (string opt)

This commit also changes the option named
index.[X].elasticsearch.index-creation-sleep (just introduced in
979eb87d89bd019f20f82ed6ebf98842a24d3f2c) to
index.[X].elasticsearch.create.sleep.

For #840
Deleting the ES index creation conf-file option

This option was analogous to the client settings conf-file option,
except this one controlled settings specific to the request Titan
sends to create an index in ES.  Not worth adding another conf-file
option for this, particularly before the relative-path hack for
conf-file options is cleaned up and integrated into the ConfigOption
system.

For #840
AsciiDoc for new ES index creation customization

This documents the changes in 6569f8b060a86a6291326e76f5dbe612732b2f7f
and f3f79b6120736d30f442f78d59eb62efe8a8d4dd.

It doesn't mention the sleep time setting introduced in
979eb87d89bd019f20f82ed6ebf98842a24d3f2c.

For #840
Tweaking ThreadLocal comment
Support ThreadLocal and CHM for Kryo caching

This commit adds the `graph.kryo-instance-cache` option.  It takes
either the value THREAD_LOCAL (default) or CONCURRENT_HASH_MAP.  This
commit effectively restores the old Kryo caching behavior of
KryoSerializer, where it stored Kryos in a ThreadLocal, and where
those ThreadLocals are not necessarily removed when Titan shuts down.
The CHM setting provides an alternative that, unlike ThreadLocal, is
exposed to synchronization overhead when retrieving cached Kryos, but
which also releases all of its cached Kryo references when the graph
is shutdown.

For #840
Add Cardinality & Multiplicity enum shell imports

The Cardinality.* and Multiplicity.* enum names are now imported
automatically in gremlin.sh and rexster-console.sh as distributed with
Titan.

For #869
Add test of Cmp.EQUAL with array value

This test fails currently

For #878
Make Cmp.EQUAL array-aware

Array values are now compared with Apache Commons ArrayUtils.isEquals,
which is essentially Arrays.equals, but safe for multidimensional
arrays.
Make Multiplicity/Cardinality explicit in examples

For #869
Deduplicate common ES & Lucene support tests

LuceneIndexTest and ElasticSearchIndexTest both implement a
testSupport() method that runs assertions on index.supports(...) with
a variety of datatypes, mappings, and predicates.

Most (but not all) of these testSupport() method bodies were identical
between the two test classes.  The common segment has been extracted
to the shared parent class IndexProviderTest as a new method named
testCommonSupport().

This change is intended to simplify upcoming REGEX-related test
changes in LuceneIndexTest for #879
Enable REGEX tests on Lucene

Added a test of Text.REGEX that explicitly specifies Mapping.STRING so
that it will activate on Lucene.

This commit also makes LuceneIndex report that it supports REGEX,
though the implementation just throws an exception right now.  The
tests are failing.  Implementation is up next.

For #879
Modify LuceneIndex to support REGEX on STRINGs

Lucene (at least at our present version) does not seem to provide a
Filter implementation that does regex matching.  It does provide a
Query implementation for regex matching.  LuceneIndex was only built
to generate Filters; it always used MatchAllDocsQuery.  This change
modifies LuceneIndex to allow the convertQuery method to build both a
Filter and an accompanying Query.

The Lucene REGEX tests introduced in
8f712e70d767313fa4ad401bd295e9bff9fd97bf pass at the moment.

For #879
Minor javadoc improvement on lock status class
Tweak ConsistentKeyLockerTest's expired lock tests

This introduces a pair of tests around expired lock behavior:

* Check that our own expired locks throw a new ExpiredLockException
  class when checked

* Check that expired locks left behind by other instances, or by the
  current instance but with a different-than-expected write time, do
  not necessarily throw an exception in check (unless they prevent the
  transaction from verifying one or more of its own locks)

Previously, only the latter case was implemented and tested.  The
former case is essentially a special case for #892, wherein we want to
provide a more meaningful exception type and message in the event that
a transaction's locks expire while held.