[SYCL][DOC] Physical memory IPC specification, generic handle struct and related aliases.

[slawekptak]

Introduce the following changes to the extensions specifications:

• Add IPC support for sycl::ext::oneapi::experimental::physical_mem object (sycl_ext_oneapi_inter_process_communication).
• Introduce a new handle struct and handle_data_t and handle_data_view_t aliases in the generic sycl::ext::oneapi::experimental::ipc namespace, and use this types for the physical memory IPC. These types will be used for all other IPC related features going forward (sycl_ext_oneapi_inter_process_communication).
• Add properties argument to the physical_mem constructor (sycl_ext_oneapi_virtual_mem).

[Copilot]

Pull request overview

This PR updates the sycl_ext_oneapi_inter_process_communication extension specification to generalize IPC handle representation and to specify IPC support for sycl::ext::oneapi::experimental::physical_mem, while also aligning the existing USM IPC text with the new direction.

Changes:

• Introduces generic IPC handle types under sycl::ext::oneapi::experimental::ipc (handle, handle_data_t, handle_data_view_t).
• Adds a new “Inter-process exchange of physical memory” section with ipc::physical_memory::{get, open} APIs and the new device aspect.
• Updates USM IPC documentation to fix examples/calls and explicitly marks ipc_memory::handle as backward-compatibility-only pending an ABI break.

[gmlueck]

It would be better not to define this namespace alias in the synopsis. I don't want people to think that the identifier syclext is part of the public API. In the function declarations below, I think you don't need the namespace qualifier because C++ rules will look in all parent namespaces. Therefore, it should be OK to declare the functions like:

handle get(const physical_mem &phys_mem);

The implementation should also not define the namespace alias syclext for the same reason.

Same comment for the other places where you have defined namespace aliases.

[slawekptak]

My point was to emphasize that handle used here is a different type from the one used in ipc_memory namespace, but it is a good point that we shouldn't suggest that the alias is part of the API.