baseparse: do not accumulate buffers on passthrough mode

If on passthrough during reverse playback, do not accumulate buffers as
baseparse will never check for DISCONT flag to push those buffers.
So just push buffers downstream as if it was forward playback.

https://bugzilla.gnome.org/show_bug.cgi?id=721941
tests: baseparse: add basic test for baseparse

Just a small test to check that basic playback works
tests: baseparse: add test for reverse playback on passthrough

Baseparse stores buffers for reverse playback to push on the next
DISCONT, the issue was that it wouldn't ever check for a discont
on passthrough mode as it skips all real parsing. This test
was create to verify this issue and prevent it from happening again

https://bugzilla.gnome.org/show_bug.cgi?id=721941
collectpads: take offset into account for expected segment position

The firt valid segment position is start + offset.
Also add some more debug and a FIXME
segment: take offset into account in _to_position()

Take the offset into account when converting between running-time and
segment positions.
baseparse: do not ignore TIME segments

TIME segments are being ignored and a standard initialized
segment is used instead. This causes issues as not properly detecting
reverse playback or not cliping output based on the segment.

This seems to be a regression from one of the GstSegment/GstEvent
redesigns on the 0.10 -> 1.0 transition
segment: add method to offset the segment running-time

Add a method that can apply an offset to the calculated running-time of
a segment.
pad: use new segment offset method to apply the offset

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721422
tests: add unit test for segment _offset_running_time()

Add a unit test to check that positive and negative offsets are applied
correctly in various cases.
tests: improve check, also check stream-time
segment: gst_segment_offset_running_time() will be available in 1.2.3
multiqueue: prevent buffering forever with playbin

When prerolling/buffering, multiqueue has its buffers limit set
to 0, this means it can take an infinite amount of buffers.

When prerolling/buffering finishes, its limit is set back to 5, but
only if the current level is lower than 5. It should (almost) never be
and this will cause prerolling/buffering to need to wait to reach the
hard bytes and time limits, which are much higher.

This can lead to a very long startup time. This patch fixes this
by setting the single queues to the max(current, new_value) instead
of simply ignoring the new value and letting it as infinite(0)

https://bugzilla.gnome.org/show_bug.cgi?id=712597
pad: fix sticky event leak after sticky_events_foreach

events_foreach adds an extra ref when giving the event to the
user function. In case it was unrefed by the user, this extra ref
disappeared, but events_foreach still should unref again to
lose its own ref before removing the event from the array.

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