Don't use .clone() on tracks to render them in demos

[lminiero]

@fippo made me aware of an incorrect use of the WebRTC APIs in our multistream demos, and namely the fact we were using clone() on MediaStreamTrack instances (both local and remote) to render them. The motivation for using .clone() was that, especially for remote streams, we can now have more than one audio and/or video track in the same stream, and so relying on the "original" stream wouldn't allow them to be playable in <audio> or <video> elements. That said, while the principle is correct, the way we were "solving" this wasn't, as explained in this issue where the bug was reported.

As such, this PR changes all the .clone() instances, to pass the track directly in the MediaStream constructor instead. This means that, wherever we had something like this:

stream = new MediaStream();
stream.addTrack(track.clone());

we do this instead:

stream = new MediaStream([track]);

This is a PR and not a direct commit just to give people the chance to test all demos and ensure they still work as expected. I tried a few, especially those involving multiple streams, and they all seemed to be fine, but you may want to test this yourselves as well and provide feedback before I merge (which will be soon).

[lminiero]

Merging.

[fippo]

and I did not even have to compare track cloning to putting 🍍 on 🍕 ;-)

[nakkag]

I have imported this merge into my program and now the video stops in Chrome.

Plug-in is video room.
Reproduced in Chrome on desktop and Chrome on Android.

When you are a subscriber in Chrome, if there is packet loss at the publisher, an onmute/onunmute will occur in the subscriber.
This will trigger the onremotetrack event.
When the track is stopped in the onremotetrack, the onunmute no longer occurs and the video is stopped.

If ".clone()" is added with addTrack, even if the track is stopped in onremotetrack, onunmute will occur and the video will be displayed again.

Reference
#2145