MODE-1365 Migrate JCR query functionality into 3.x

Migrated part of the JCR query functionality from 2.x into the 3.x codebase. Our query engine basically does the following:

1. the user supplies a query string and language specification
1. find the parser for the specified language
1. the parser converts the query string into a query object model
1. the query object model is converted to a canonical plan defining the various relational operations; each leaf is an access node defining a query that can be issued against the indexes
1. the canonical plan is validated against the known schema (build from the registered node types); an exception is thrown if there are any errors
1. the canonical plan is optimized using a rule-based optimizer (each rule rewrites the plan)
1. the optimized plan is then used to create a processing plan, where the processing plan contains a processor for each relational operation in the optimized plan
1. the processing plan is executed; the access nodes' queries are issued against the indexes and converted into tuples, and these tuples are passed through each relational operation processor. The final tuples for the query are then pushed out the top of the processor, and made available to the user via the JCR QueryResult object. Since every tuple contains the keys for all nodes used in that tuple, we can easily find the corresponding nodes.

Here's a summary of the new 3.x packages, and where in 2.x the code originated.

* `org.modeshape.jcr.query` package contains the main components for executing queries (the engine, results, etc.), plus the implementations of the `javax.jcr.query` interfaces. Most of these classes were moved from the 2.x `org.modeshape.graph.query` and `org.modeshape.jcr.query`.
* `org.modeshape.jcr.query.model` package contains the query model objects, which are simply used to create an object representation of a query (by the parsers). The model objects have a built-in visitor system, which is used several different ways. (For example, producing a string representation of a query model is done with a `ReadableVisitor`.) In 2.x we had a JCR-independent query system in `org.modeshape.graph.query.model` that were subclassed by the JCR QOM implementations in `org.modeshape.jcr.query.qom`; these have all be merged and simplified into a single set of classes that also implement the JCR QOM interfaces.
* the `org.modeshape.jcr.query.parser` package contains an abstract SQL parser from which the JCR-SQL and JCR-SQL2 parsers extend, plus the full-text search parser (used by our full-text search language and by the JCR-SQL2 parser). The parsers parse a string query and always generate a single query model. The classes were moved from the 2.x `org.modeshape.graph.query.parser` package plus a few parser-related classes from the `org.modeshape.jcr.query' package. The XPath-related parser is in a separate package (see below).
* the `org.modeshape.jcr.query.plan` package contains a canonical planner that converts the query model into a general tree-based query plan, with separate plan nodes representing the various relational operators. Note that joins are represented as a parent node with two sub-plans (this is what makes it a tree). All leaf nodes are access nodes that describe a single query that can be pushed to the source (e.g., Lucene); the number of access nodes is usually 1+j, where j is the number of joins. Note that the canonical plan is validated. All of these classes were moved from the 2.x `org.modeshape.graph.query.plan` package.
* the `org.modeshape.jcr.query.optimize` package contains the rule-based optimizer and the optimizer rules. The optimizer takes a canonical plan and produces another "optimized" plan (which may or may not reuse nodes from the original plan). This process is called rewriting, and each rule basically looks for some pattern, rewrites it, and then outputs the (possibly) updated new plan. This new plan is then passed to the next rule, and the process continues. At the end of the process, the new "optimized" plan represents something that we can execute. All of these classes were moved from the 2.x `org.modeshape.graph.query.optimize` package.
* the `org.modeshape.jcr.query.process` package contains the components that can execute an optimized query plan. Again, a tree of processing nodes is created, where each processing node represents and implements a relational operation (e.g., project, select, join, limit, distinct, etc.). Execution of a node implies pulling tuples from lower node(s), performing the operation, and returning the (new) tuples. (Note that this is a very simplistic design that can be improved at a later time.) All of these classes were moved from the 2.x `org.modeshape.graph.query.process` package.
* the `org.modeshape.jcr.query.validate` package contains the validator that checks the canonical plan to ensure that is represents a valid, executable query. The package also contains the classes to describe the "schema" of the tables and columns that can be queried, and part of validation includes ensuring that the queries conform the the schema. (Since "schema" is an overloaded term, we use the term "schemata" in the code.) Validation is implemented as a visitor. All of these classes were moved from the 2.x `org.modeshape.graph.query.validate` package.
* the `org.modeshape.jcr.query.xpath` package contains the XPath parser and language objects, plus the translator the converts an XPath (in language object form) into a normal relational query model. After that, the XPath queries are handled the same way as query models from other languages. In 2.x, these classes were in the `org.modeshape.jcr.xpath` package.

At this point, all parsing and query object model code and the corresponding tests have been moved. However, there is still additional work:

1. we're not building Lucene indexes
1. we haven't implemented the processor that implements the access nodes, so queries aren't executable
1. the Session/Workspace changes have not been made

I'm now looking into how we can leverage Hibernate Search to have a more scalable solution for our Lucene indexing and querying.