Enable sort optimization for all NumericTypes

[gashutos]

Is your feature request related to a problem? Please describe.
Lucene provides inbuilt sort optimization (point based) for all numeric sort types. As per this PR we were able to enable sort optimization for below 4 types.

1. DATE
2. DATE_NANOSECONDS
3. LONG
4. DOUBLE

There are other types where we have widened our Types (i.e from SHORT to LONG). Code. So those types are still not optmized and taking time to return hits.

Describe the solution you'd like
Enable Lucene numeric sort optimization for all remaining types mentioned here.
Code

Describe alternatives you've considered
There is no alternative as of now.

Additional context
This will break existing indexed data, so we need to do POC and determine challenges to enable optimizations where SortField.Type is not matched with Point.Type.

        // LUCENE-9280 added the ability for collectors to skip non-competitive
        // documents when top docs are sorted by other fields different from the _score.
        // However, from Lucene 9 onwards, numeric sort optimisation requires the byte size
        // for points (BKD index) and doc values (columnar) and SortField.Type to be matched.
        // NumericType violates this requirement
        // (see: https://github.com/opensearch-project/OpenSearch/issues/2063#issuecomment-1069358826 test failure)
        // because it uses the largest byte size (LONG) for the SortField of most types. The section below disables
        // the BKD based sort optimization for numeric types whose encoded BYTE size does not match the comparator (LONG)/
        // So as of now, we can only enable for DATE, DATE_NANOSECONDS, LONG, DOUBLE.
        // todo : Enable other SortField.Type as well, that will require wider change

[andrross]

However, from Lucene 9 onwards, numeric sort optimisation requires the byte size for points (BKD index) and doc values (columnar) and SortField.Type to be matched. NumericType violates this requirement (see: #2063 (comment) test failure) because it uses the largest byte size (LONG) for the SortField of most types.

@nknize Do you happen to know why OpenSearch/ES chose to use a LONG for the SortField for the smaller types? I suspect I'm not the only one who would like to know so it might be helpful to capture that here. (Or link to anywhere else that might explain it). Thanks!

[gashutos]

@nknize @reta raised above PR to enable sort optimization for all remaining types. Let me know if approach looks good...