RTCBrowserType.supportsSimulcast(). Add TODOs.

Simplifies the main condition as suggested by H. Terezov

Fixes an issue where the user would end up stuck in disconnected if
the video muted signalling arrived after the timeout. Also reactors
the way how the output status is figured out.

This is only temporary, since we suspect that the calculation for the
receive direction is incorrect.

If there was no notification from the JVB about the connectivity status
it means it's connected. That's because the bridge does not send any
notification unless there is a problem.

Cleans up code. Paces the increase of connection quality. Take ramp-up
into account. Uses sending bitrate by default whenever possible (with
and without simulcast, as long as we know the sending bitrate and
resolution).

Updates the packet loss based calculation (used whenever we don't know
the sending bitrate and input resolution) with hard-coded thresholds,
so that it doesn't scale linearly (15% packet loss doesn't yield 85%
connection quality).

When the remote track which caused to transit to the disconnected status
is removed from the conference the current status received through
the data channels should be used to avoid getting out of sync by missing
"muted"/"unmuted" events sequence.

Usually the track removed is replaced by the new one(in our use cases),
but the new track is always added unmuted. Now if the connection gets
restored in the meantime while the track is being signalled then
the 'muted/unmuted' event sequence may be missed and the participant
might be blocked in the "disconnected" state forever.