[SYCL] Use L0 queries for L0 devices

[mgouicem]

This PR replaces OCL queries with matching L0 queries for L0 devices on Intel devices.
Few notable things:

• Updated L0 headers to access some recent queries
• Added headers for Intel specific L0 extensions. These headers come from compute-runtime. We asked about forward compatibility status of these symbols and are waiting for clarification (hence why this PR is in draft)
• switched ngen to dynamically load L0

[mgouicem]

make test
disable device_cpu
enable device_gpu
enable thr_sycl
enable thr_ocl

[petercad]

You can actually omit the calls to zeInit as the caller must invoke L0 prior to entering nGEN (to locate the device, create a context, etc.).

[petercad]

Do we have a driver support matrix? Users may have pretty old drivers (esp. on Linux), so I'm wondering if we need a fallback path here.

[mgouicem]

For backward compatibility, we validate only last driver available at time of release (see README). In this particular case, this query appeared on Oct 31st 2023 (99abb40a)

For forward compatibility, I am working on getting clarification (and this PR will remain draft in the meantime).

[petercad]

No GPUs currently have floating point atomic adds in local memory, so we just need to know about global memory FP atomic support:

Suggested change

	= ZE_DEVICE_FP_ATOMIC_EXT_FLAG_GLOBAL_ADD
	| ZE_DEVICE_FP_ATOMIC_EXT_FLAG_LOCAL_ADD;
	= ZE_DEVICE_FP_ATOMIC_EXT_FLAG_GLOBAL_ADD;

I think a similar change makes sense for load/store and min/max.

[mgouicem]

I aligned with the native_extension definition that was used so far from OCL queries here (flag is set only if both local and global are available).

I am fine changing the semantic of native_extensions (it seems broken anyway as you mention). But that might have wider implications.

[petercad]

Good point. Then I think it makes sense to keep L0 and OCL aligned and change both in a future PR.