Use index sort range query when possible.

[jtibshirani]

This PR proposes to use IndexSortSortedNumericDocValuesRangeQuery when possible to speed up certain range queries. Points-based queries are already very efficient, the only time this query makes a difference is when the range matches a large number of documents.

Some notes:

• The optimization is only applied for fields of type date, integer, and long. I found that the query implementation isn't yet suited for double or float types (I will follow up with a Lucene issue).
• Before applying the query, we check that the index is sorted on the query field. This isn't strictly necessary, since the query itself checks this as part of its execution. But it seemed nice to avoid wrapping the query unnecessarily -- it makes debugging easier, like when reading search profile results.

Below are benchmark results on the http-logs dataset. The following ranges were run against the logs-241998 index:

range-small (897633930, 897655999]: ~2M docs
range-medium (897623930, 897655999]: ~5M docs
range-large (897259801, 897503930]: ~21M docs

| Metric                       |         Task |    Baseline |   Contender |     Diff |   Unit |
|-----------------------------:|-------------:|------------:|------------:|---------:|-------:|
| 50th percentile service time |  range-small |     11.0228 |     8.19478 | -2.82797 |     ms |
| 95th percentile service time |  range-small |     11.8153 |     9.06257 | -2.75274 |     ms |
| 50th percentile service time | range-medium |     22.8912 |     7.23264 | -15.6585 |     ms |
| 95th percentile service time | range-medium |     25.0957 |     7.93246 | -17.1632 |     ms |
| 50th percentile service time |  range-large |     39.7224 |     6.34589 | -33.3765 |     ms |
| 95th percentile service time |  range-large |     43.9104 |     7.06604 | -36.8444 |     ms |

Relates to #48665.

[elasticmachine]

Pinging @elastic/es-search (:Search/Search)

[jimczi]

LGTM

[jtibshirani]

Thanks @jimczi for the review.