New cl_khr_command_buffer_mutable_memory_commands extension

Discussion issue for the functionality to be able to update the parameters to memory operation commands in a command-buffer after the command-buffer has been finalized using the `clUpdateMutableCommandsKHR` entry-point defined by `cl_khr_command_buffer_mutable_dispatch`. Defined in a new layered extension - `cl_khr_command_buffer_mutable_memory_commands`

The initial API draft to implement this functionality used a find/replaced based lookup for `cl_mem` objects used as command parameters. However this was not determined to be a robust solution as 1) src/dest could potentially be the same buffer for commands like `clCommandCopyBufferRectKHR` and 2) can't change non cl_mem parameters to commands like `size`

An alternative draft was therefore designed which has a specific struct for each command that gives configurations per command which solves these issues. See https://github.com/KhronosGroup/OpenCL-Docs/pull/1065 for the PR containing the extension draft using this mechanism.

A drawback of this design, other than being more verbose, is that is requires the users to keep around all of the original information about the command. They can't just put in a new `cl_mem` if that's the only aspect of a command they want to update, they need to put in the new `cl_mem` and then also reinsert the original information about the command.

To get around this drawback it was proposed we could have reusable structures per command. e.g. A struct for updating the source `cl_mem`, as struct update the destination `cl_mem`, a struct for updating both the source and destination `cl_mem`, etc. Whether we want to go forward with this API proposal is where the discussion should be continued from.

Start by reading the linked pull request 1065 and the discussion around clUpdateMutableCommandsKHR and the proposed reusable per-command structures. Done requires a settled API direction for cl_khr_command_buffer_mutable_memory_commands, followed by an updated extension draft.

Written by the indexing model from the issue text.