MODE-2181 Added supported for SNS to the REST service via support of JSON arrays.
MODE-2181 Changed the REST service tests to use Apache HttpClient. This allowed some previously disabled tests to be re-enabled.
Modified a couple test cases to make sure the node does not have the unqualified property. There might be other tests needed to verify other situations.
MODE-2167 Added the ability to turn off ACLs if all policies were removed.
MODE-2018 Implemented new query engine.

Refactored the query functionality to now use several new service provider interfaces (SPI),
and implemented a new query engine that can take advantage of administrator-defined indexes.
When no such indexes are defined, the query engine is able to still answer the queries
by "scanning" all nodes in the repository. This is like a regular relational database:
all query functionality works (albeith slowly) even when no indexes are defined, though
to improve performance simply define an appropriate index based upon the query or queries
that are being used.

All of ModeShape's query parsing, planning, and optimization steps are basically unchanged
from the previous query system. There is one addition to the rule-based optimizer: a new
rule looks at query plans and adds the potential indexes that might be of use in each
access query portion of a query plan. Then, the query execution process (see below)
chooses one of the identified indexes based upon the selectivity and cardinality. If no index
is available for that portion of the query plan, then the query engine simply iterates
over all queryable nodes in the repository.

A new kind of component, called a "query index provider", allows the query engine to delegate
various responsibilities around indexes to these providers. For example, a provider must
provide an index planner that can examine the constraints that apply to an access query
and determine if any of the provider's indexes can be used. When they are, ModeShape
adds those indexes to the query plan. If the query engine uses one of those indexes,
then provider must be able to return all of those nodes that satisfy the criteria
as described earlier by its index planner. Finally, as ModeShape content changes, ModeShape
will notify the index providers' of the changes so that they can ensure their indexes
are kept up-to-date with the content.

This means that a provider can implement the functionality using any kind of technology,
and consequently, that ModeShape can begin to leverage multiple kinds of search and index
technology within its query system. The ModeShape community anticipates having providers
that use Lucene, Solr, and ElasticSearch. ModeShape will also likely come with a provider
that maintains file-system based indexes. Additionally, providers can optionally support
indexes on one or more properties. Thus, it will be possible to mix and match
these providers, selecting the best technology for the specific kind of index.

The new query engine does the execution in a very different way than the previous engine,
which used Lucene to determine the tuples (that is, the values in each row) for each access
query and that were then further processed and combined to form the tuples that were returned
in the result set. The new engine instead uses a new concept of a "stream of node keys"
for each access query: what actually implements that stream depends on many factors.
A node sequence is an abstraction of a stream of "rows" containing one or more node keys.
The interfaces are designed to make it possibly to lazily implement a stream in a very
efficient manner. Specifically, a node stream is actually comprised of multiple "batches"
of rows, and batches can be of any size.

Consider when the engine findes no indexes are available for a certain access query. The
engine simply uses a "node sequence" (or NodeSequence) implementation that returns in batches
a row for each node in the repository.

But if an access query involves a criteria on the path of a node, such as
"... WHERE ISSAMENODE('/foo/bar') ...", then ModeShape knows that this query (or portion of
a query) will have only one result, namely the node at "/foo/bar". ModeShape doesn't need
an index to quickly find this node; it merely has to navigate to that path to find the one
node that satisfies this query. ModeShape has several other optimizations, too: it knows
when a query involves all children or descendants of a node at a given path, and can take
this into account when optimizing and executing the query. All of these are handled with
special NodeSequence implementations optimized for each case.

For many access queries (i.e., part of a larger query), the engine will use one of the
indexes identified by one of the providers. When this happens, ModeShape uses other
NodeSequence implementations that utilize the underlying indexes to find the nodes that satisfy
some of the criteria.

The above describes how the engine uses a single NodeSequence instance for each each access
query in a larger query. But how does the engine combine these to determine the ultimate
query results? Basically, the engine constructs a series of functions that process one or more
NodeSequence instances to filter and combine into other NodeSequences.

For example, a custom index might be used to find all nodes that have a 'jcr:lastModified'
timestamp within some range. Presumably this index is used because it has a higher selectivity,
meaning that it will filter out more nodes and return fewer nodes than other indexes.
Other criteria that are also applied to this access query might then be applied by a filter
that processes the actual nodes' property values.

While the result of this commit is a functioning query engine that is shown to work in most
of the query-related unit and integration tests, there still are a few areas that are not complete.
Specifically:

* The new engine does not support full-text search, and currently throws an exception
* No index providers are implemented. Therefore, all queries involve "scanning" the repository.
This can be time consuming, especially for federated repositories. Consequently, all such
tests that query federated content have been disabled/ignored.
MODE-2018 Upgraded MapDB to 0.9.11

Upgraded the MapDB dependency and fixed an apparent memory leak by moving the
BufferManager (used in the new query engine) to be owned by the session, ensuring
that it is garbage collected properly when the session is closed.

Also changed how the BufferManager allocates DB instances to be more lazy, since
MapDB 0.9.11 appears to have more overhead.
MODE-2184 Added a public 'close' method to QueryResult public API.
MODE-2018 Made several improvements following a code review
MODE-2169 Added an assembly descriptor which zips the Javadocs.
MODE-2175 Changed the vendor.url property so it doesn't get messed up in the productization process.
MODE-2138 Added test to verify order by path works with new query engine
Updated release notes for 4.0.0.Alpha1
MODE-2169 Added the 'example-with-dependencies' assembly descriptor that was incorrectly removed in a recent commit
MODE-2177 Updated the JavaDoc configuration to reflect Java 7 and removed the no-longer-working JBoss stylesheet
Corrected the modeshape-client assembly mechanism, which was broken since the dependencies were changed.
Corrected compiler and JavaDoc warnings
MODE-2187 Force the use of IPv4 for the jbossas-kit-tests, since Arquillian may have trouble connecting via IPv6.
Updated package sections in JavaDoc
Updated release script to deal with new name of Wildfly distribution (rather than EAP distribution)
MODE-2171 Updated the document & system export code to avoid exporting anything ACL related and to also check READ permissions on each of the nodes being exported.