[SYCL] Deprecate parallel_for and single_task overloads

[HPS-1]

As the title says, added deprecation messages for such overloads in the sycl_ext_oneapi_kernel_properties extension, suggesting users to use single_task/parallel_for overloads provided in the sycl_ext_oneapi_enqueue_functions extension instead. (As these overloads are to be removed later as mentioned in #14785) Also fixed affected test cases by adding the Wno-deprecated-declarations build flag to let them ignore the deprecation warnings.

Also one point to notice:

1. The following overload in the handler class is actually implemented as three function overloads with range<dimensions>... implemented as range<1>..., range<2>... and range<3>... respectively.

   template <typename KernelName, int dimensions, typename PropertyList, typename... Rest>
   void parallel_for(range<dimensions> numWorkItems,
                    PropertyList properties,
                    Rest&&... rest);

[EwanC]

Graph tests LGTM

[againull]

All deprecation messages indicate that sycl_ext_oneapi_enqueue_functions should be used instead of deprecated APIs.

But do I get it right that user also has a choice to use just regular SYCL 2020 parallel_for/single_task/parallel_for_work_group (queue and handler methods) but with kernel function object (which has a method to return properties) instead of a lambda? I.e. it seems like user doesn't have to use sycl_ext_oneapi_enqueue_functions. Maybe I am missing something.

Probably deprecation message should be fixed to indicate both available options.

[HPS-1]

All deprecation messages indicate that sycl_ext_oneapi_enqueue_functions should be used instead of deprecated APIs.

But do I get it right that user also has a choice to use just regular SYCL 2020 parallel_for/single_task/parallel_for_work_group (queue and handler methods) but with kernel function object (which has a method to return properties) instead of a lambda? I.e. it seems like user doesn't have to use sycl_ext_oneapi_enqueue_functions. Maybe I am missing something.

Probably deprecation message should be fixed to indicate both available options.

Hi Artur, thanks for reviewing this! So just to let you know I've merged all commits in this PR into one in another PR #16728 to make the commit history cleaner. You can go there for further comments and check new updates.

And yes I agree with you -- the main point here is that if the user want to specify (compile-time) properties for a kernel, they can no longer specify such properties as arguments passed to (overloads of) single_task() and parallel_for(). Instead, they need to use kernel functors with the get(sycl::ext::oneapi::experimental::properties_tag) method to return properties. In other words, whether the single_task()/parallel_for() used are from original SYCL or extensions doesn't matter much (as long as they aren't among these deprecated ones). Sorry about the mis-wording here, I'll fix it in that other PR.

[againull]

All deprecation messages indicate that sycl_ext_oneapi_enqueue_functions should be used instead of deprecated APIs.
But do I get it right that user also has a choice to use just regular SYCL 2020 parallel_for/single_task/parallel_for_work_group (queue and handler methods) but with kernel function object (which has a method to return properties) instead of a lambda? I.e. it seems like user doesn't have to use sycl_ext_oneapi_enqueue_functions. Maybe I am missing something.
Probably deprecation message should be fixed to indicate both available options.

Hi Artur, thanks for reviewing this! So just to let you know I've merged all commits in this PR into one in another PR #16728 to make the commit history cleaner. You can go there for further comments and check new updates.

And yes I agree with you -- the main point here is that if the user want to specify (compile-time) properties for a kernel, they can no longer specify such properties as arguments passed to (overloads of) single_task() and parallel_for(). Instead, they need to use kernel functors with the get(sycl::ext::oneapi::experimental::properties_tag) method to return properties. In other words, whether the single_task()/parallel_for() used are from original SYCL or extensions doesn't matter much (as long as they aren't among these deprecated ones). Sorry about the mis-wording here, I'll fix it in that other PR.

Sounds good, thank you!