concat: Add new element that concatenates multiple streams

https://bugzilla.gnome.org/show_bug.cgi?id=734470
concat: Add documentation and integrate into documentation build
concat: Add unit tests for concat element
docs: Trivial pad documentation fix

Presumably a copy-pasto.
multiqueue: Post errors ourselves if they are received after EOS

After EOS there will be no further buffer which could propagate the
error upstream, so nothing is going to post an error message and
the pipeline just idles around.
queue: Post errors when receiving EOS after downstream returned an error

There might be no further data flow that would allow us to propagate the
error upstream, causing nobody to post an error at all.
queue2: Post errors if we receive EOS after downstream reported an error

There will be no further data flow that would allow us to propagate the
error upstream, causing nobody at all to post an error message.
element: Clarify docs about gst_element_get_request_pad() and remove deprecation part

This function is not really pad or slow for the common case of requesting a
pad with the name of the template. It is only slower if you to name your pads
directly instead of letting the element handle it.

Also there's no reason to deprecate it in favor of a more complicated function
for the common case.
bin: gst_bin_new() can accept NULL as name
bin: Use allow-none instead of nullable until we depend on a new enough GI version
multiqueue: Only handle flow returns < EOS as errors, not e.g. flushing
multiqueue: Not post BUFFERING message if one of the singlequeue doesn't need it

Imagine the following 'pipeline'

                --------------
            p1/| 'fullqueue'  |--- 'laggy' downstream
  ---------  / |              |
-| demuxer |   | multiqueue   |
  ---------  \ |              |
            p2\| 'emptyqueue' |--- 'fast' downstream
                --------------

In the case downstream of one single queue (fullqueue) has (a lot of) latency
(for example for reverse playback with video), we can end up having the other
SingleQueue (emptyqueue) emptied, before that fullqueue gets
unblocked. In the meantime, the demuxer tries to push on fullqueue, and
is blocking there.

In that case the current code will post a BUFFERING message on the bus when
emptyqueue gets emptied, that leads to the application setting the pipeline state to
PAUSED. So now we end up in a situation where 'laggy downstream' is
prerolled and will not unblock anymore because the pipeline is set to
PAUSED, the fullequeue does not have a chance to be emptied and
the emptyqueue can not get filled anymore so no more BUFERRING message
will be posted and the pipeline is stucked in PAUSED for the eternity.

Making sure that we do not try to "buffer" if one of the single queue
does not need buffering, prevents this situtation from happening though it lets the
oportunity for buffering in all other cases.

That implements a new logic where we need all singlequeue to need
buffering for the multiqueue to actually state buffering is needed,
taking the maximum buffering of the single queue as the reference point.

https://bugzilla.gnome.org/show_bug.cgi?id=734412
bus: destroy signal watch from the context it was mapped to

Don't rely on g_source_remove() because it operates on the main
context. If a signal watch was added to a new thread-default context
g_source_remove() would have no effect. So simply use
g_source_destroy() to avoid this problem.

Additionally the source_id was removed from GstBusPrivate because it
was redundant with the signal watch GSource also stored in that
structure.

https://bugzilla.gnome.org/show_bug.cgi?id=734716
base: remove g-i annotation that makes older g-ir-scanner crash

Just remove one skip annotation that causes this:

  ** (g-ir-compiler:12458): ERROR **: Caught NULL node, parent=empty

with older g-i versions such as 1.32.1.
base: and fix build with new g-i again
inputselector: always proxy caps query

Otherwise it would only be proxied for the active pad which can lead
upstream to use an incompatible caps for the downstream element.

Even if a reconfigure event is sent upstream when the pad is activated, this
will save the caps reconfiguration if it is already using an acceptable caps.
docs: make explicit that the caps passed to gst_base_src_set_caps() are 'tranfer none'

https://bugzilla.gnome.org/show_bug.cgi?id=733741
bytereader: add gst_byte_reader_peek_sub_reader() and _get_sub_reader()

Adds API to get or peek a sub-reader of a certain size from
a given byte reader. This is useful when parsing nested chunks,
one can easily get a byte reader for a sub-chunk and make
sure one never reads beyond the sub-chunk boundary.

API: gst_byte_reader_peek_sub_reader()
API: gst_byte_reader_get_sub_reader()
queue: fix race when flush-stop event comes in whilst shutting down

Don't re-start the queue push task on the source pad when a
flush-stop event comes in and we're in the process of shutting
down, otherwise that task will never be stopped again.

When the element is set to READY state, the pads get de-activated.
The source pad gets deactivated before the queue's own activate_mode
function on the source pads gets called (which will stop the thread),
so checking whether the pad is active before re-starting the task on
receiving flush-stop should be fine. The problem would happen when the
flush-stop handler was called just after the queue's activate mode
function had stopped the task.

Spotted and debugged by Linus Svensson <linux.svensson@axis.com>

https://bugzilla.gnome.org/show_bug.cgi?id=734688
tests: add test that triggers deadlock in state change of queue

When receiving FLASH_STOP in a state transition to READY, a queue
element can end up with an active task that will never end.

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