Now that down streams have labels, we need to distinguish on the
stream direction.

Delete the stop video button, it is now redundant.  Panic remains.

Don't maintain loss, which is too error-prone.  Instead, maintain
expected and received packet counts, and compute loss from that.

Needed to show in the user list whether a user is publishing a stream.

We now create a sendonly transceiver, and set the max bitrate at
creation time.

We used to label tracks individually, in a view to using the labelling
for simulcast.  Since then, the WebRTC community has converged on a
different strategy, where multiple tracks share a single mid and
are labelled with the rid extension.

We now label whole streams, which is simpler, and use the track's
kind (and, in the future, the rid) to disambiguate.  This changes the
protocol in two ways:

  * in offers, the "labels" dictionary is replaced by a single "label"
    field; and
  * the syntax of the "request" message has changed.

The server now maintains a set of statuses for each user that are not
interpreted by the server but communicated to the other members of the
group using 'user' messages.

We now maintain the user list in the serverConnection.

Everything now goes through onclose, both for up and down streams.

Since we don't use a separate RTX SSID, we must explicitly account for
NACKed packets in our loss statistics.

This removes the need to hardcode the footer height in a CSS calc().

The signature class was forcing the maximum height making the <p>
element overflowing the page. By removing this constraint, the overflow
is now gone.

This is useful for people writing administrative interfaces.

Use matchMedia to check if mobile css is enabled instead of checking window innerwidth size.

Uses less javascript to update css style, rework buttons css for show/hide video and chat.
Fix show or hide video button on normal or mobile ui when windows is resized or when orientation change.

Thanks to gregfr.