oneAPI: Bump to v2025.0.0

[maleadt]

Binary counterpart of JuliaGPU/oneAPI.jl#480. Removes the libOpenCL workaround we had in place, and also switches back to GCC now that the SYCL headers seem patched, and to avoid what looks like a Clang bug.

Specifically, with Clang we run into the same issue we had the previous time around:

ERROR: could not load library "/home/tim/Julia/src/Yggdrasil/O/oneAPI_Support/build/x86_64-linux-gnu/1wcmn0N3/x86_64-linux-gnu-libgfortran5-cxx11/destdir/lib/liboneapi_support.so"
/home/tim/Julia/src/Yggdrasil/O/oneAPI_Support/build/x86_64-linux-gnu/1wcmn0N3/x86_64-linux-gnu-libgfortran5-cxx11/destdir/lib/liboneapi_support.so: undefined symbol: _ZN6oneapi3mkl6lapack21gebrd_scratchpad_sizeIfTnPNS1_8internal9enable_ifIXsr5is_fpIT_EE5valueEvE4typeELPv0EEElRN4sycl3_V15queueElll

Taking a closer look, this symbol is provided by libmkl_lapack, but slightly differently mangled:

_ZN6oneapi3mkl6lapack21gebrd_scratchpad_sizeIfTnPNS1_8internal9enable_ifIXsr5is_fpIT_EE5valueEvE4typeELPv0EEElRN4sycl3_V15queueElll

Both however demangle to the same signature: long oneapi::mkl::lapack::gebrd_scratchpad_size<float, (void*)0>(sycl::_V1::queue&, long, long, long). I'm not sure who or what's to blame here; icpx is also Clang based, and generates the correct mangled string... Switching back to GCC works around the issue.