Clarify format of `new VideoFrame(CanvasImageSource)`

When creating a VideoFrame from a CanvasImageSource, the most obvious choice of format is an RGBA one. However, if the frame is going to be read back and encoded with 4:2:0 subsampling, creating a 4:2:0 frame in the first places can save half of the memory bandwidth.

I would propose that we explicitly allow implementations to choose the format of VideoFrames created in this way. In the future we will likely want to add a hint. This could just be the same format enum, but an implementation could interpret I420 as a hint for 4:2:0 and choose to create an NV12 frame. Alternatively the hint could be just in the form of a subsample resolution if that is more clear.

Under this proposal, Chrome's implementation might in some cases use a 4:2:0 format for accelerated CanvasImageSources when no hint is provided.

We could be more strict, but I suspect it's rarely better to fail or do a much more expensive operation. A VideoFrame conversion API is better suited to precise format transformations.

Start with the VideoFrame(CanvasImageSource) constructor and review the existing issue discussion. Define whether implementations may choose the format, how an optional format or subsampling hint would work, and what behavior should be specified for accelerated CanvasImageSources. The proposal is complete when the format-selection semantics and compatibility expectations are precise.