check: Disable multiqueue test_output_order check

The check itself is racy.

 (CK_FORK=no GST_CHECK=test_output_order make elements/multiqueue.forever).

The problem is indeed the test and not the actual element behaviour.

The objects to push are being pulled out of the single internal queues in the
right order and at the right time...

But between:
* the moment the global multiqueue lock is released (which was used to detect
if we should pop and push downstream the next buffer)
* and the moment it is received by the source pad (which does the check)

=> another single queue (like the unlinked pad) might pop and push a buffer
downstream

What should we do ? Putting a bigger margin of error (say 5 buffers) doesn't
help, it'll eventually fail.

I can't see how we can detect this reliably.

https://bugzilla.gnome.org/show_bug.cgi?id=708661
tests: use tcase_skip_broken_test() to skip broken multiqueue test

So that we get a warning in the output that reminds us that
something needs to be fixed.
docs: fix function name in qos design docs
collectpads: Call the collected function while it returns FLOW_OK

This allows us to make sure the elements is EOS and does not have
remaining buffers to be drained.

https://bugzilla.gnome.org/show_bug.cgi?id=709637
caps: Add a testcase for subset checks on lists with duplicated items

https://bugzilla.gnome.org/show_bug.cgi?id=709253
docs: Fix some reference URIs

https://bugzilla.gnome.org/show_bug.cgi?id=709804
caps: Skip test_subset_duplication until the bug is fixed

https://bugzilla.gnome.org/show_bug.cgi?id=709253
core: Fix max DEBUG_LEVEL incongruence on 5 vs 9

In the docs and the autocompletion logic the maximum
value jumped incongruently between 5 and 9.
parse: Fix transfer annotations for parse_launch functions.

gst_parse_launchv, gst_parse_launchv_full and gst_parse_launch_full
all return floating refs, the same as gst_parse_launch, which just
calls gst_parse_launch_full internally anyway.

Add a unit test assertion to check it's true.

Spotted by nemequ on IRC.
tests/filesrc: Set location in wrong state

Also remove incorrect comment about code possibly not being reachable
that is now exercised by the filesrc unit test.

https://bugzilla.gnome.org/show_bug.cgi?id=709831
docs: Add gst_pad_store_sticky_event to sections.txt

So it appears in the generated documentation
datetime: Make sure to include gst_private.h before glib-compat-private.h

We need to define the GLib log domain before including glib.h, which is
included by glib-compat-private.h.
net: Constify a parameter to gst_net_client_clock_new()

Even though this parameter is not used, it should be const to fit in with the
coding standards for other similar parameters. Client code already passes in
const strings under the expectation that they won’t be modified.

https://bugzilla.gnome.org/show_bug.cgi?id=710442
docs: Gram and nit fixes for part-memory.txt
docs: Gram and nit fixes for part-messages.txt
docs: Gram and nit fixes for part-buffering.txt
docs: Gram and nit fixes for part-bufferpool.txt
docs: Gram and nit fixes for part-buffer.txt
docs: Gram and nit fixes for part-caps.txt
docs: Gram and nit fixes for part-clocks.txt