Clear clReImportSemaphoreSyncKhr semantics for use after signal/wait

[joselopeqti]

Fixes #1407

Currently the spec doesn't specify what would be the behavior if you call clReImportSemaphoreSyncKhr after signaling or importing that semaphore.
As it is stated that "Calling clReImportSemaphoreSyncFdKHR is equivalent to destroying sema_object and re-creating it with the original sema_props from clCreateSemaphoreWithPropertiesKHR", this PR requires an interleaving wait, so no semaphore payload is left behind.

[CLAassistant]

All committers have signed the CLA.

[kpet]

2025/09/16 memory TSG teleconference: do we need a more precise definition of what constitutes performing an operation? Is a query an operation? Does "perform[ing]" mean executing a command or enqueuing a command? This needs to be clarified.

[joselopeqti]

In this context "perform" covers both enqueue and execution. We are open to proposals that would help to clarify the meaning of the text.

[bashbaug]

Does it make sense to refer to the queried value for CL_SEMAPHORE_PAYLOAD_KHR here? This isn't sufficient to cover cases where the semaphore has pending signals or waits enqueued, so perhaps additional text is still required, but if the (binary) semaphore payload is zero to indicate that it is in the un-signaled state then I think it is a more precise way of saying "the last operation performed on sema_object was a wait".

[joselopeqti]

We believe that referring to the queried value might not be enough due to possible pending signals and waits. We are leaning towards a condition like:
"The last enqueued command to reference the semaphore should be clEnqueueWaitSemaphoresKHR and the semaphore should be in the un-signaled state."