Some bricks specialized by ExecutionPolicy without apply std::decay_t

[SergeyKopienko]

In this PR we fix the issue #2110

As we discussed with @rarutyun we still need to have EcecutionPolicy in bricks from architecture point of view.

This PR is a new copy of #2112

Implementation details

Now in all struct __brick_... implementations we have new static_assert :

static_assert(std::is_same_v<_ExecutionPolicy, std::decay_t<_ExecutionPolicy>>);

So we will have compile error if we use brick with non-decayed policy.

[SergeyKopienko]

@akukanov, @rarutyun could you please take a look to this PR ?

[danhoeflinger]

My first reaction to this is that it is very likely a good change.
However, I think we need to wait to consider this in the context of a larger discussion about differing reference types of arguments (Policy and ranges) and SYCL kernels, which I hope will happen in the next couple weeks.

We first need to decide what the expected behavior is when a user passes different flavored reference types of policies and ranges, and if that changes for different contexts:

1. no unnamed lambda vs unnamed lambda
2. same kernel name specified vs different kernel name specified vs none specified

Once we have some conclusions about expected behavior there, we can figure out the best steps to achieve that.

I believe something like this will be part of the solution. However, I would resist merging any related changes until we can take a step back and consider it at from a higher level.

[danhoeflinger]

(If a user is waiting on a specific fix for a build error, that may change the calculus here, but I don't think that is the case)

[akukanov]

Here comes a subjective cosmetic nitpicking :)

In this and many other functions, _DecayedExecutionPolicy is only used once in its definition scope. Meanwhile, it saves just 7 symbols, comparing to std::decay_t<_ExecutionPolicy>, and adds nothing to readability.

I see little value in the alias even where it is reused, and absolutely zero (that is, -273 :)) reasons to add it when used only once.

[SergeyKopienko]

I am ready to any variant, it's not problem....

[SergeyKopienko]

Fixed