Add CI workflow to build and test dpnp with the open source LLVM SYCL compiler (#3048)

This PR adds a manually-triggered CI workflow that builds and tests dpnp
against the open source `intel/llvm` DPC++ (LLVM SYCL) nightly
toolchain, instead of the released Intel oneAPI compiler. This gives
early warning when an upstream compiler change breaks dpnp, and
exercises the source against a second, independent SYCL implementation.
Building against the open source nightly surfaced one real correctness
bug in dpnp (fixed here) and required a few build-system adjustments,
all included.

### What is added

- `.github/workflows/os-llvm-sycl-build.yml` — `workflow_dispatch` job
that downloads the latest `intel/llvm` nightly compiler, the OpenCL CPU
runtime (oclcpuexp) and oneTBB, builds dpctl and dpnp from source
against the nightly (dpnp built against the oneMath interface), and runs
the full `dpnp/tests` suite.
- `.github/workflows/bump-sycl-deps.yml` — weekly (Saturday) workflow
that opens a PR when a newer oclcpuexp driver release or oneTBB release
is available, keeping the pins in `os-llvm-sycl-build.yml` current. The
nightly compiler itself is discovered at run time and is not pinned.
- `dpnp/backend/cmake/Modules/IntelSYCLConfig.cmake` — parse the open
source compiler version string (`clang version X.Y.Z`) in the vendored
module, which is forced for this build because the nightly does not ship
`add_sycl_to_target()`.

### Correctness fix

Building the ufunc extension with the open source nightly exposed an ODR
violation in
`dpnp/backend/extensions/ufunc/elementwise_functions/populate.hpp`: the
`MACRO_POPULATE_DISPATCH_*` macros defined the helper structs
`ContigFactory`, `StridedFactory` and `TypeMapFactory` with the same
name in the shared `dpnp::extensions::ufunc::impl` namespace across
every per-ufunc translation unit, each with a different body. The Intel
compiler inlines these away, but the open source compiler emits them as
weak COMDAT symbols and folds the identically-named instantiations
across translation units, so several binary ufuncs got their dispatch
and result-type tables populated from the wrong translation unit.
Observable effect: `fmin`, `fmod`, `heaviside`, `logaddexp2` and `ldexp`
silently computed the elementwise maximum, and the integer result-type
entries for `fmin`, `fmax`, `fmod`, `gcd` and `lcm` were dropped. The
fix gives the factories per-ufunc-unique names so no two translation
units share a symbol. 3590fe3

Author: github-actions[bot]