Screen: Make libdc1394 video recording engine multi-threaded.

So far video recording in the Firewire engine was driven
synchronously by the master thread. Extend the implementation,
so that the 'recordingflags & 16' setting allows to run recording
asynchronously in a dedicated realtime background processing thread.

Each camera with active video recording gets its own thread. The
thread runs at realtime priority with a level of +1 wrt. master
thread. The thread periodically polls for new video frames from
the dc1394 capture engine, dequeues them, optionally pre-processes
them (Bayer filtering or YUV->RGB conversion), and pushes them into
the GStreamer video recording pipeline. It also provides the frames
for retrieval by the masterthread via the usual Screen('GetCapturedImage')
function.

If low-latency "frame dropping" capture is requested in
Screen('StartCapture',...), the thread will poll at 1 msec intervals,
push all captured frames to video encoding, but only provide the
most recently deqeued frame in a special bounce buffer "current_frame",
so that the master thread will always only get that frame.

Non-dropping mode is tbd. It modifies the GStreamer pipeline to
feed all video frames into an additional appsink with sufficient
capacity and the master thread will pull frames from the appsink
in FIFO order, so no frames ever get lost for the consuming script.

Regular synchronous "old school" recording and capture is still used
if no async recording is requested.

The current implementation works reasonably well when tested with
sync / async recording, single camera and multi-camera, free-running,
bus-synced or ttl-synced. What is missing is a little bit of logic to
make sure each thread pulls the same amount of frames when capture
is stopped. This is not an issue in hw-synced mode, but a small issue
in bus/software-synced mode. In synced mode, all cameras stop their
capture at the same time and therefore all DMA queues contain the same
amount of pending frames at end of capture, but as the threads stop
at slightly different points in time, they will be able to pull and
encode different numbers of those frames from the DMA queues before
they die. This needs to be solved by explicite use of some barrier.

-> Screen.mex for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo.m extended with multicam recording support.