sort_index: use of only int_index iterators inside sort_index

[jvdp1]

This PR aims to simplifiy the implementation of sort_index, without modifying the API. So, sort_index still accept an array index of kind int_index or int_index_low, but all iterations and counts are internally done using int_index integers.
This is a first step to extend sort_index to a procedure that accepts an array index of a intrinsic type integer, real, complex, ....

Note: these changes partly revert some changes done in #829 and can be compared against #824 (see here for a comparison with the original implementation)
Note2: these changes are in agreement with the implementation in ord_sort.

cc: @perazz @jalvesz

[perazz]

I like the fact of uniforming all internal size handling to 64-bit integes. The code is clearer, less need for pre-processing, and may be even more performing on some platforms. LGTM.

I was wondering if you think there may be issues on some 32-bit platforms i.e. #694, but I see tests OK with 64-bit integers there, so, all good I think.

[jvdp1]

I was wondering if you think there may be issues on some 32-bit platforms i.e. #694, but I see tests OK with 64-bit integers there, so, all good I think.

Thank you @perazz . I see that ord_sort (that relies on int64 integers) was OK on #694. So, I guess it is fine.

[jvdp1]

As this PR does not modify the current API, and only slightly modifies the implementation of sort_index (by mainly cleaning it and coming back to its original version), I will merge this PR and open another one related to @jalvesz issue in #760