Use builder pattern to construct result set objects
Add UnindexedMatcher to evaluate whether a doc rev matches a selector

This commit only adds the matcher object and tests, it doesn't tie
them in to the query pipeline.

The class currently takes a fairly simple two stage approach:

1. Transform the selector into a tree composed of OR, AND and
expression nodes.
2. Allow a document to be matched against the transformed selector.

Step 1:

Here we transform selectors like:

 AND : [ { OR : [ { x: X }, { y: Y } ] }, { y: Y } ]

Into trees like:

               AND
              /   \
           OR   { y: Y }
         /    \
  { x: X }  { y: Y }

The leaves are still NSDictionary objects, composed of the operator
expressions from the selector (e.g., { "name": { "$eq": "mike" } } ).
This could be better optimised for execution over large result sets,
I imagine, as the operator expressions still need interpretation for
each candidate document. However, until profiling indicates this
requirement, I've chosen to leave them in dictionary form as this makes
the code simpler.

Parsing out the AND and OR nodes in a separate step seems to simplify
the execution step, by placing a bit of dictionary munging and
normalisation separately upfront.

Step 2:

This is just walking the tree creating in step one, evaluating as we go.
Operator expressions are evaluated, returning YES or NO. AND and OR
nodes simply evaluate their child nodes, then apply AND or OR to the
results. Eventually this recursive process has been through the whole
selector and the result of the match can be returned.

Support:

This implementation supports:

$and, $or, $not
$eq, $ne, $gt, $gte, $lt, $lte, $exists

It supports array values in document revisions, and checks whether
any of the array values match the selector.
Run matcher for queries with one or more missing index

This commit allows this implementation of Cloudant Query to
execute queries which contain fields that have not been
indexed.
Disable invalid format tests

Pending moving selector validation into a new class.
Test full vs. SQL only vs. UnindexedMatcher results

This commit adds tests to try and make sure that the
separate query types give the same results:

- the full SQL + UnindexedMatcher engine (the standard one)
- using only the SQL indexes (for queries covered by indexes)
- using only UnindexedMatched (over all documents in store)