Clarify impl deferal of clUpdateMutableCommandsKHR

Address point 1) of KhronosGroup#1309
by clarifying when an implementation may defer propogating
the changes from `clUpdateMutableCommandsKHR`.

I belive the only semantic implication of this is the removing the
restriction
> This is only possible with a command-buffer created with the CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR flag, as without this the enqueued command-buffer must complete before any modification occurs.

So that implementations without simultaneous use support can still
defer.

Author: EwanC

api/opencl_runtime_layer.asciidoc

@@ -16199,15 +16199,10 @@ kernel commands using that object as an argument have had their arguments
 replaced with a different object.
 ====
 
-To facilitate performant usage for pipelined work flows, where applications
-repeatedly call command-buffer update then enqueue, implementations may
-defer some of the work to allow {clUpdateMutableCommandsKHR} to return
-immediately.
-Deferring any recompilation until {clEnqueueCommandBufferKHR} avoids
-blocking in host code and keeps device occupancy high.
-This is only possible with a command-buffer created with the
-{CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR} flag, as without this the enqueued
-command-buffer must complete before any modification occurs.
+Implementations may defer some of the work to allow {clUpdateMutableCommandsKHR}
+to return immediately, provided the user observable behavior in subsequent
+command-buffer usage is specification conformant. Deferring work helps keep
+device occupancy high by avoiding blocking in host code.
 
 [open,refpage='clUpdateMutableCommandsKHR',desc='Modify configuration of mutable-command handles to update behavior for future enqueues',type='protos']
 --