Tighten spec for extension queries

[aarongreig]

UR_DEVICE_INFO_EXTENSIONS and UR_PLATFORM_INFO_EXTENSIONS both return strings denoting "extensions supported" by the underlying adapter. The current implementations can return some pretty weird stuff, like cuda reporting support for a couple of OpenCL extensions, and a PI extension the line below that. In fact, OpenCL extension strings are reported by all the adapters. I suspect this behaviour is relied on by some element of the sycl RT but it isn't a good mechanism for communicating what it's trying to communicate, and we should definitely aim to get rid of it.

Beyond that a conversation needs to be had about what these queries are for. We deliberately avoided calling the various experimental features extensions, although we are now seeing some of them appear in the output of these queries. If we want them to be a mechanism for reporting support for UR experimental features then the spec should reflect that. If we want them to return extensions supported by the underlying API (i.e. have the CL adapter continue reporting CL extension strings) then that should explicitly be in the spec as well. I question the usefulness of both of these. Unless there's a compelling use case for returning native extension strings (which you could still do if you really wanted, by getting the native handle out), or reporting experimental feature support via a string rather than a ur_device_info_t enum like we mostly already do, we should consider these queries vestigial and remove them.

[JackAKirk]

I used the extension string for extension testing: #1369
Following command_buffer extension precedent.

[aarongreig]

yeah that's partially what prompted this issue, I'm not going to argue against its use there since there's an established precedent

[alycm]

Discussed 2024-02-28, removing OpenCL extension string here makes sense, but should check that this won't affect current SYCL-RT code.