This is a rather large and complex change. It comprises several parts:

(1) Instead of directly sending EOS, segment, and sample events to the
    downstream DirectShow sink, first queue them in a local buffer (i.e.
    "pin->event").

(2) Spawn a separate thread per source pin (i.e. "stream_thread") which consumes
    said events and sends them downstream.

(3) When flushing or stopping, explicitly wait for this thread to pause or stop
    (respectively).

There are a few reasons for this:

(1) It reduces the number of Unix -> PE callbacks we need to make, easing PE
    conversion. This is not a great advantage *a priori*, and may not be worth a
    similar dedicated "handler" thread for most modules, but winegstreamer is
    different—we were already marshalling these calls onto another thread, and
    now that marshalling can go away (almost).

(2) Because GStreamer can only do pad negotiation (and hence autoplugging) while
    running (in contrast to DirectShow, which can do it while stopped), we
    currently have to renegotiate every time the pipeline is started. Most
    applications don't start the graph more than once, but even that requires
    two negotiations, and startup time is demonstrably too high. It would be
    nice to keep the graph in PAUSED state all of the time, but this is
    difficult to do without more fine-grained control over the streaming thread.
    [In particular, we cannot reliably wait for all samples to be delivered
    except by stopping the GStreamer pipeline.]
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>