[UR] Update spec to make kernel argument validation in urEnqueueKernelLaunch optional

[RossBrunton]

Migrated from oneapi-src/unified-runtime#2564

Several adapters don't support validating kernel signatures when
enqueued. To handle this, we now allow urEnqueueKernelLaunch to return
SUCCESS even when parameters are invalid.

[npmiller]

I wonder if we should just say that passing incorrect kernel arguments is "undefined behavior" or something like that.

As shown in the test, if an adapter is unable to validate the arguments it's unlikely to be able to gracefully return success as well.

If we want to keep some level of argument validation, maybe it could be guarded behind a device property?

[RossBrunton]

I'm not sure the benefits of marking it as UB are worthwhile, especially since I don't think we have (explicit) UB anywhere else in UR. Cuda seems to be the only target with major issues with invalid arguments, do you see that resulting in UB?

[npmiller]

Well it also segfaults on HIP, where we don't have a straightforward way of validating arguments either. So there's at least two targets where this doesn't really work.

And it seems to me that it defeats the purpose of making argument validation optional if we want targets to still do something specific when the arguments are wrong, if we could tell that the arguments are wrong then we'd just return the correct error code.

As it stands we can't tell if the arguments are wrong or not, so we just let the underlying API do whatever it can, which for CUDA seems to be to returning invalid value, and for HIP just segfaulting, if we want to fix that to return success, we pretty much circle back to having to validate the arguments in UR.

[RossBrunton]

#17953 Discussed this internally, and this might be a better approach that works on all adapters.