[rbp] Fix for hang after seeking introduced by ASS fix

#2206 introduced a regression when seeking in some types of SD files where the video stutters and/or stalls.
This is caused by using the wrong clock in FlipPage
[rbp] Fix for stuttery video when seeking before zero

There are a few issues with seeking I found.
We weren't correctly setting OMX_BUFFERFLAG_TIME_UNKNOWN on the first frame after a seek which could make the GPU think video was at 0 and audio at a much larger offset.
A full video fifo (to GPU) stops any higher priority messages from being received which can stall a seek and the flush message doesn't get through. Use m_flush to discard the video packet that doesn't fit.
We get an audio frame through with unknown pts/dts after the flush, but before the GENERAL_RESYNC when seeking. This was given to GPU and was perhaps 30 seconds out from the following packets and that throws off the timing between audio and video streams. Keeping m_flush true until the GENERAL_RESYNC discards this frame. Hopefully that is safe.
[rbp] [wip] new scheme for handling stalling and buffering

There's two types of under run that can occur on Pi in xbmc:
1. Unable to stream fast enough (e.g. wifi + hdmi audio passthrough)
2. Lack of CPU (e.g. wired ethernet + software DTS)

The first behaves well, and xbmc buffers for a number of seconds giving the buffers a chance to fill up.
The second case behaves less well. It doesn't go into buffering mode and just continuously stutters.

This patch makes both cases buffer. It also means we start paying with a full buffer of decoded audio which should maximise the time until we under run (which could avoid buffering at all on a marginal file).
It also fixes a bug where m_endtime was used without being initialised which meant we left the stall state early.