qtdemux: drain the adapter before pushing EOS

In a fragmented scenario, qtdemux is operating in push mode
and it gets a fragmented buffer. While processing its data
downstream gets unlinked (or a input-selector changes its
active pad and returns not-linked). Qtdemux stops processing
this fragment and returns not-linked upstream, leaving the
remaining data in its adapter.

When it gets an EOS it should make sure that all the data it
had received is pushed before pushing EOS.
qtdemux: improve mss_mode/fragmented special handling

Make it clear what should be handled purely by mss mode:
1) Expose the streams on the first moof as there are no moov atoms
2) Properly cleanup streams on flushes

Add a note about the meaning of upstream_newsegment and mss_mode
for future reference.

Make all other special fragment handling shared for both dash
and mss streams.
wavpackdec: Send a CAPS event in the unit test
jitterbuffer: take more accurate running-time for NACK

Don't use the current time calculated from the tmieout loop for when we
last scheduled the NACK because it might be unscheduled because of a max
packet misorder and then we don't accurately calculate the current time.
Instead, take the current element running time using the clock.
rtpsession: use RTT from the Retransmission event

Place the estimated RTT in the Retransmission event and let the session
manager use that instead of the hardcoded value.
rtpjitterbuffer: calculate average jitter
rtpjitterbuffer: dynamically recalculate RTX parameters

Use the round-trip-time and average jitter to dynamically calculate the
retransmission interval and expected packet arrival time.

Based on patches from Torrie Fischer <torrie.fischer@collabora.co.uk>

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711412
rtpbin: allow dynamic RTP/RTCP encoders/decoders

* gst/rtpmanager/gstrtpbin.[ch]: four new action signals have been
  added (request-rtp-encoder, request-rtp-decoder, request-rtcp-encoder
  and request-rtcp-decoder). The user will be able to provide encoders
  or decoders dynamically. The encoders must follow the srtpenc API and
  the decoders the srtpdec API. Having separate signals for RTP and RTCP
  allows the user to use different encoders/decoders or provide the same
  one (e.g. that would be the case for srtpenc).

  Also, rtpbin now allows application/x-srtp in its pads.

  https://bugzilla.gnome.org/show_bug.cgi?id=719938