Clarify VideoFrame.copyTo() parallel steps and buffer handling

[Djuffin]

Avoid accessing or mutating JS objects from background parallel steps in VideoFrame.copyTo():

• Check if destination is detached before starting the copy.
• Capture [[resource reference]], options, and PlaneLayout results synchronously on the event loop thread (fixing PlaneLayout.stride to use destinationStride).
• Perform RGB pixel format and color space conversion on the media resource in parallel instead of synchronously constructing a temporary VideoFrame and recursing.
• Write directly to shared memory in parallel when destination is backed by a SharedArrayBuffer; otherwise, copy into destination on a queued event loop task after re-verifying detachment and byteLength (while allowing UAs to copy synchronously when the resource is already in CPU memory).
• Set the default value of VideoFrameCopyToOptions.colorSpace to "srgb" in IDL.

Fixes #955

---

Preview | Diff

[youennf]

It seems it should also be happening if |sharedMemory| is not null.

[youennf]

|sharedMemory| definition is somehow ambiguous, it is not clear whether keeping a ref to it is protecting destination's memory from being GCed.
Maybe destination.[[ArrayBufferData]] is what we need.

[youennf]

This note will likely trigger web compatibility troubles, for instance:

let buffer = new Uint8Array(...);
videoFrame.copyTo(buffer); // do not await here.
channel.postMessage(buffer, [buffer]);

As per the above algorithm, no data would be copied to buffer in copyTo.
If implementing the note, copyTo will copy data to buffer before buffer is transferred.

It seems we should either remove that note or make it mandatory.
I am also not sure why doing things synchronously avoids an extra copy.