[oneDPL][ranges] support size limit for output for merge algorithm

[MikeDvorskiy]

[oneDPL][ranges] support size limit for output for merge algorithm.
The change is according to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3179r2.html#range_as_output

1. serial pattern
2. parallel pattern (tbb)
3. parallel pattern (openMP)
4. parallel pattern (serial backend)
5. parallel pattern (DPCPP backend)

Update: Changes to draft status, causing faced to design issue, connected with different return types from the merge patterns - __result_and_scratch_storage/__result_and_scratch_storage_base. As an option - to have one common type of __result_and_scratch_storage for the all needs (ate least for pattern dpcpp merge patterns).
Update 2: the issue mentioned above has been resolved.

[danhoeflinger]

All my feedback has been resolved, so LGTM. We have an agreement to target some change from #2003 for 2022.9.0.

I believe that some others (@SergeyKopienko @dmitriy-sobolev @mmichel11) may have been more involved in reviewing and looking at details in changes from their feedback recently, so I suggest getting approval also from one or more of them.

Finally, we should wait for green CI (other than the docs, looks like that is systemic and unrelated).

[akukanov]

This is funny :) @MikeDvorskiy you explained to me that using indexes as the parameters of this function is to avoid computing the indexes twice. But in the serial implementation you do not really use indexes but switch back to the iterators :) which only confirms my impression that ___merge_path_out_lim should use iterators as its parameters.

[MikeDvorskiy]

I told that I was going to avoid twice computation for new output size
const _Index3 __n_out = std::min<_Index3>(__n_1 + __n_2, std::ranges::size(__out_r));

And in parallel version ___merge_path_out_lim __n_1, __n_2, n_out are used.
As far as we already computed these values in __pattern_merge, I just pass ones into ___merge_path_out_lim.

Also I kept in mind that __serial_merge_out_lim may be used (re-called) from the iterator-based merge in the future. That's why I kept iterators in the signature of __serial_merge_out_lim.

[akukanov]

The thing is, you do not need __n_out for the serial version. In the serial loop, it's not a problem to check on each iteration if the end of the output is reached.

[MikeDvorskiy]

..
Basically, only parallel version of ___merge_path_out_lim needs const _Index3 __n_out = std::min<_Index3>(__n_1 + __n_2, std::ranges::size(__out_r)); logic.
So, we can move the mentioned logic inside the function. (and pass iterators from the __pattern_merge).

[SergeyKopienko]

LGTM

[danhoeflinger]

re-approving after minor changes