Undeprecate legacy multi_ptr

[steffenlarsen]

The legacy decoration for multi_ptr has been made the default template argument of the decoration in multi_ptr to bridge the gap between SYCL 1.2.1 and SYCL 2020 multi_ptr interfaces. However, the legacy decoration and the specialization of multi_ptr with the decoration is deprecated with SYCL 2020. This is confusing to users as they may easily run into deprecation warnings simply due to not specifying the decoration. This commit proposes that we remove the deprecation of legacy in SYCL 2020.

[steffenlarsen]

Note that async_work_group_copy using legacy multi_ptr is still deprecated. We can undeprecate them, but their signatures will be slightly different from the yes-no deprecated ones.

[VerenaBeckham]

How about the statement in programming_interface.adoc:

Note that using [code]#global_ptr#, [code]#local_ptr#, [code]#constant_ptr# or
[code]#private_ptr# without specifying the decoration is deprecated.
The default argument is provided for compatibility with 1.2.1.

Should that also be removed as part of this PR?

[steffenlarsen]

How about the statement in programming_interface.adoc:

Note that using [code]#global_ptr#, [code]#local_ptr#, [code]#constant_ptr# or
[code]#private_ptr# without specifying the decoration is deprecated.
The default argument is provided for compatibility with 1.2.1.

Should that also be removed as part of this PR?

Good catch! It has been removed.

[VerenaBeckham]

I can't comment on whether this change is the right thing to do, but the code LGTM.

[AerialMantis]

I think we also need to update the change log, that currently states that the legacy option for multi_ptr is deprecated.

• legacy 1.2.1 interface (deprecated).

[AerialMantis]

I think we might need to update the change log as well, but other than that this change LGTM.