Clarify "Clone Configuration" to eliminate TOCTOU race possibility

[chcunningham]

Clone Configuration is used in the various isConfigSupported() steps (example) to make a copy of the config as seen by the UA in assessing "support". The steps in "Clone Configuration" make a recursive shallow copy of the given config. For configs that contain a "description" BufferSource member, this should mean the output config points to the same BufferSource as the input config (copy by reference). This opens the possibility of TOCTOU races where the user may pass the config to isConfigSupported() and then modify the buffer while isConfigSupported() is asynchronously checking for support. It seems better to instead make a deep copy of the BufferSource in the synchronous portion of isConfigSupported().

Similarly, we should probably make deep copy (using the same clone algo) in the synch steps of configure().

[padenot]

We've run into this while implementing in Gecko.

Let's make a copy here if nobody objects. It seems to be what Chromium implements, and is tested in a WPT.

@youennf, do you know what WebKit implements here? Do you have any comment?