Add support for maxHits

Currently there are 3 mechanisms to control # of hits for a query

• Use of the timeAllowed query parameter - Though this does not directly control the number of hits, it has a similar effect with the collector terminating after the specified time budget has exceeded. The primary objective of this switch is to control runaway queries.
• Use of segmentTerminateEarly{{ __ }}parameter - This parameter is only applicable for sorted segments where the sort criteria requested matches the sort criteria used in the SortingMergePolicy
• Use of cpuAllowed parameter to put upper bound on cpu time for a query.

I would like to propose a new maxHits parameter. This parameter early terminates the query once it has gone past the provided number of hits per shard.

For us the  motivation for such a parameter is the following:

Our search is extremely latency sensitive and the query set is a mix of very high frequency tokens where we favor fast recall and typical search queries where we favor precision at low latency. The former can be thought of as a search as you type use case and we want to ensure that we return the results quickly and just go over enough documents we plan to control via the maxHits parameter.  We can't use a sorted index for our use case because the sort criteria is a ranking function which is based off document features and the user input.

With the maxHits parameter, it is quite likely that the results returned might not be the most relevant ones, however that is acceptable for us.