fix(JitsiConference): sync up local tracks

[paweldomas]

It can happen that a new session is started while JingleSessionPC operation is in progress.

Queue up the track operation on the new session to make sure it catches up with the correct tracks state.

Example:

1. JitsiConference.replaceTrack(camera1, camera2);
2. At the time there's only JVB session, it's replaceTrack will take 100ms.
3. 50 ms later - a P2P session is started, it will use camera1 as "local tracks" to start the session, because the replacement has not finished yet and this.rtc.localTracks still contains camera1.
4. Another 50ms later, JVB session finishes the replaceTrack and here we see that there's a new P2P session. Schedule a catch-up replaceTrack operation and make it part of the original addTrack operation chain.

[paweldomas]

The tests are failing, because JVB conference uses "_getInitiaLocalTracks" while the P2P session uses "getLocalTracks".
The difference between the two is that "_getInitiaLocalTracks" filters out "start with muted" tracks, while "getLocalTracks" just adds all of them. This means that there are two parallel track operation planes, one for P2P and one for JVB.

There will be a crash in case where audio track is added initially and then removed just after (which is the case for start with audio muted, because for some reason jitsi-meet gets involved). If we call remove on the track that was skipped due to start audio/video muted that will fail with unable to find transceiver, because that track was never part of the JVB connection yet.

I may give up on this fix for now, things are just too complicated and trying to fix this case will add yet more "ifs" everywhere and complicate things even more.