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.
Throw new ExpiredLockException when applicable

This commit modifies ConsistentKeyLocker and its superclass to
implement the new behavior expected in
6ea5ebf8d0b13c025d08a4734037fb725d0e089c.  Previously, a lock that
expired while a transaction was holding it would throw a cryptic
TemporaryLockingException with the message "No lock columns found for
KeyColumn [k=foo, c=bar]".  This is not a helpful exception in most
cases; the log for ConsistentKeyLocker emits a WARN about the expired
lock shortly before this is thrown, but it would be better to have a
specific exception type and message to make it clearer about what's
happening in this case.

Now we have ExpiredLockException.  This is a a subclass of
TemporaryLockingException.  The message string used with it is
something like "Expired lock on KeyColumn [k=foo, c=bar]: raw lock
timestamp 1418915175000000 MICROSECONDS is older than Duration[300000
ms]".