Do not use deprecated sub-group load/store extension

[dmitriy-sobolev]

Code sections which use sycl::sub_group::<load()|store()> DPC++ extension are not entirely disabled. Non-template expressions are still checked by a compiler even if they are within a discarded if constexpr branch.

This makes the code non-compatible with compilers other than DPC++, and it results in a deprecation warning with the most recent DPC++ builds.

A mock-up example: https://godbolt.org/z/svhnY14r5

[MikeDvorskiy]

1. This is a "logic mix" of preprocessor code and C++ code.... It looks a mess..
   I would recommend "take a look/imagine" on C++ code which remains after the preprocessor keeps one branch "#if" and the other branch "#else" and make the code clean-up (here and everywhere in that PR).

2. BTW, _ONEDPL_LIBSYCL_SUB_GROUP_LOAD_STORE_PRESENT is defined as identical zero.
   https://github.com/oneapi-src/oneDPL/pull/1979/files?diff=split&w=0#diff-521f7db06a55567c1a1dffa855dde585fb6bc5fbe8633d19b528356e3a501ea0R91
   M.b. it makes sense to remove the branches _ONEDPL_LIBSYCL_SUB_GROUP_LOAD_STORE_PRESENT at all?

[dmitriy-sobolev]

I've removed all the branches. Initially, they were there to preserve the logic if we decide to add newer versions of sub-group load/store. If we settle with this, I can create an issue to remember this optimization opportunity.

[mmichel11]

Removing the sub-group load store logic seems fine to me as it is currently unused. It may be worth creating an issue to investigate the performance difference and determine if it is worth it to adopt.

I suggest we wait for @adamfidel's input when he returns since I believe he introduced sub-group load / store path here.

[adamfidel]

Thanks for cleaning this up. The idea was to come back and re-enable this code path at a later point, but since this has been dead code for some time now, I agree it makes sense to just remove it for now.

[danhoeflinger]

LGTM