Improve QueryIndex interface

The current QueryIndex interface is quite simple, but doesn't address some of the required features and more advanced optimizations that are possible:

• For fulltext queries, it doesn't address the case where the index implementation has a different understanding of the fulltext condition than what is described in the JCR spec (the basic features).

• For queries with "order by" it would be good to know if the index supports returning the data in sorted order, and if yes, how much slower that would be (if it is slower). So a index might have multiple strategies with different costs.

• It's quite easy to misunderstand what getCost is supposed to do exactly. The new API should have a clearer solution here.

• Even if the query doesn't have "order by", the index might return the data in a sorted way, which might help improving query performance (using a merge join)

• The cost is currently a single value, it might be better to estimate the number of nodes, the cost to run a query, and the cost per node. That way we could optimize to quickly return the first few nodes (versus optimize for thoughput).