adaptivedemux: Workaround for live seek ranges when advancing

adaptivedemux: Workaround for live seek ranges when advancing

This is a workaround for a regression introduced by
f4190a49c04f1d5d174cebba0bc9a03a7ec721c2
 ( adaptivedemux: Check live seeking range more often )

The goal of the previous commit was to be able to cope with non-1.0
rates on live streams which have a "seeking window" (i.e. the server
keeps around quite a bit of the live stream so you can seek back into
it).

Without that commit, two different kind of issues would happen:
* When doing reverse playback, you would never check whether you
  are outside of the seekable region. And would then continuously
  try to download fragments that are no longer present.
* When doing fast forward, you would end up requesting fragments
  which are not present yet.

In order to determine whether one was *really* outside of the seekable
window, we check whether the current stream position is still
within the seekable region.

The *problem* though with that commit is that it assumes that subclasses
will return continuously updated seeking ranges (i.e. dependent on the
current time), which is *NOT* the case.

For example:
* dashdemux does use the current UTC to determine the seekable region
* hlsdemux uses the values from the last updated manifest

Therefore if one downloads fragments faster than realtime, for HLS
we would end up at the end of the last manifest seekable range, and
the previous commit would consider the stream as being ended... which
is not the case.

In the long run, we need to figure out a way to cope with non-1.0
rates on live streams for all types of stream (including HLS).

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