Fix up command-buffer enqueue error after PR-1382 (KhronosGroup#1471)

KhronosGroup#1382 added support
for deferring setting arguments on a kernel command which is updatable.
To achieve this we added an extra command-buffer state, "finalized"
which is entered when a command-buffer has been finalized but doesn't
yet have all it's arguments set.

However, if a user tries to enqueue a command-buffer in this state
it shouldn't be valid. Therefore update our current wording about
when an command-buffer can be enqueued to say the specifically the executable
state, when all arguments are available. Rather than defined as after the
finalization operation, which could result in the command-buffer being in
either the finalization or executable state.

We already have a NOTE above to this effect, which I've removed as it
felt like it didn't add any extra value above the error definition, but
can added back if folks think it's worthwhile.

Author: EwanC

api/opencl_runtime_layer.asciidoc

@@ -15122,20 +15122,15 @@ include::{generated}/api/version-notes/clEnqueueCommandBufferKHR.asciidoc[]
     application to wait on this command or query it for profiling
     information.
 
-[NOTE]
-====
-To enqueue a command-buffer it must be in a <<executable, Executable>> state,
-see {clFinalizeCommandBufferKHR}.
-====
-
 // refError
 
 {clEnqueueCommandBufferKHR} returns {CL_SUCCESS} if the command-buffer
 execution was successfully queued, or one of the errors below:
 
   * {CL_INVALID_COMMAND_BUFFER_KHR} if _command_buffer_ is not a valid
     command-buffer.
-  * {CL_INVALID_OPERATION} if _command_buffer_ has not been finalized.
+  * {CL_INVALID_OPERATION} if _command_buffer_ is not in the
+    <<executable, Executable>> state.
   * {CL_INVALID_VALUE} if _queues_ is `NULL` and _num_queues_ is > 0, or
     _queues_ is not `NULL` and _num_queues_ is 0.
   * {CL_INVALID_VALUE} if _num_queues_ is > 0 and not the same value as