blevesearch/sear should be able to handle multiple documents to accommodate query's parallelization factor

The goal is to get rid of the lock introduced with - http://review.couchbase.org/c/n1fty/+/158589

Recently discovered the query parameter - for concurrent access during verify/eval. This defaults to 1. Contention for this new lock will kick in only if the query parallelization is greater than 1.

I can think of 3 options at the moment ..

• Leave the locking in place to serialize evaluation (undesirable).
• We can update the NewVerify API for query to share the parallelization factor - so we'll need to update the sear index to be able to hold that many documents at a time (against what sear brings to the table).
• Thirdly, based on the parallelization factor - set up that many sear indexes for evaluation.