[oneDPL][ranges] A fix for ranges::transform algo - it requires all input and output ranges to be sized.

[MikeDvorskiy]

A fix according to p3179r4.
It requires all input and output ranges to be sized for ranges::transform algo.

[dmitriy-sobolev]

Looks good to me leaving aside a suggestion for std_ranges_transform.pass.

Let me leave a link to the paper and a relevant section for other reviewers and my future self: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3179r4.html#require_bounded_ranges

In the case of two input ranges or sequences, for a few algorithms - namely, mismatch, equal, and transform - it could be sufficient for just one range to be bounded and the other assumed to have at least as many elements as the bounded one.
...
However, SG9 decided to require sized_range for all inputs, with the plan to relax these constraints for transform once there is a way to statically detect infinite ranges like views::repeat (as opposed to finite unsized ranges, such as null terminated strings).

[dmitriy-sobolev]

LGTM.

This PR changes public API, though.
I would vote for merging it as is, because:

• It makes the algorithm compliant with the recent developments in C++ standard.
• This algorithm is new (it's been in oneDPL for 2 releases), which lowers the risk.

However, lets wait for the opinion of others, as we discussed separately.

[danhoeflinger]

It seems like we also need a fix for the oneDPL specification as well:

https://github.com/uxlfoundation/oneAPI-spec/blob/71f6bf676ca0b5d258373d499403f8738298e648/source/elements/oneDPL/source/parallel_api/parallel_range_api.rst?plain=1#L314

As for how to deal with any deprecation, or removal since it has already been released both in the spec and the code, it warrants some discussion.