Support compilation from SYCL source code

[sommerlukas]

This adds support to create a program/executable kernel_bundle from SYCL source code.

It uses the DPC++ kernel_compiler extension. As this is only an extension and not all backends are supported, a query on the device was added to check for support for compilation.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?
• If this PR is a work in progress, are you opening the PR as a draft?

[sommerlukas]

The kernel_compiler extension also supports SPIR-V and OpenCL as input languages, so it would be possible to replace the existing interop for SPIR-V and OpenCL with the same extension. I however did not do this as part of this PR for three reasons:

• To keep the PR scope limited
• The resulting programs wouldn't be interop anymore.
• It should probably be part of a bigger refactor that also renames program to kernel_bundle then.

[ndgrigorian]

Builds seem to be failing on the current compiler version, so this will probably need to be gated like the others behind utilities that check for the availability of the "kernel_compiler" extension

[ndgrigorian]

On the plus side, it's passing with 2025.2, and OS builds work—tests won't run until rebased on/merged with master though

[sommerlukas]

SYCL runtime compilation should also be supported with 2025.1, but the registered_names property used to be called registered_kernel_names in that release.
Also, 2025.0 might define the feature test macro, because it had support for OpenCL and SPIR-V in kernel_compiler (but no SYCL yet), but doesn't define all properties yet.

@ndgrigorian Do you know how to distinguish the different minor versions? I tried with __LIBSYCL_MAJOR_VERSION and __LIBSYCL_MINOR_VERSION, but I don't seem to get different versions.

[ndgrigorian]

SYCL runtime compilation should also be supported with 2025.1, but the registered_names property used to be called registered_kernel_names in that release. Also, 2025.0 might define the feature test macro, because it had support for OpenCL and SPIR-V in kernel_compiler (but no SYCL yet), but doesn't define all properties yet.

@ndgrigorian Do you know how to distinguish the different minor versions? I tried with __LIBSYCL_MAJOR_VERSION and __LIBSYCL_MINOR_VERSION, but I don't seem to get different versions.

Compiler also defines __LIBSYCL_PATCH_VERSION , that's the only other way I would know immediately.

[sommerlukas]

I ended up using __SYCL_COMPILER_VERSION to distinguish the different DPC++ minor versions. Based on feedback in my other PR #2038, I've also switched to using opaque pointers here and removed std::vector and other STL types from the header.