Fix parallel_for_each with C++20 iterators

[kboyarinov]

Description

C++20 changed a bit an approach to determine the iterator category - now the new member type iterator_concept was introduced and now used as a primary type defining the iterator category. Previous iterator_category typedef can be defined now into "junior" category (typically std::input_iterator_tag).
Also C++20 introduced ranges and used this approach to define iterators for views. E.g std::ranges::iota_view::iterator - see here for more details.

Currently parallel_for_each algorithm uses the "legacy" approach and determines an iterator category based on iterator_category member type. For modern iterators (e.g. std::ranges::iota_view::iterator) it will result in using more strict and less efficient implementation for input iterators that implies copying of the entire range.

This PR changes the approach to use std::random_access_iterator (and other similar) concepts to determine the iterator category that respects both iterator_concept and iterator_category types.

We faced similar issue in oneDPL, see issue uxlfoundation/oneDPL#1253 and PR uxlfoundation/oneDPL#1266

Fixes # - issue number(s) if exists

• - git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details)

Type of change

Choose one or multiple, leave empty if none of the other choices apply

Add a respective label(s) to PR if you have permissions

• bug fix - change that fixes an issue
• new feature - change that adds functionality
• tests - change in tests
• infrastructure - change in infrastructure and CI
• documentation - documentation update

Tests

• added - required for new features and some bug fixes
• not needed

Documentation

• updated in # - add PR number
• needs to be updated
• not needed

Breaks backward compatibility

• Yes
• No
• Unknown

Notify the following users

List users with @ to send notifications

Other information

[pavelkumbrasev]

LGTM!

[dnmokhov]

LGTM