Peter M. Groen / openbr

The primary addition is ProcessWrapperTransform, which takes a transform as a
child, and creates a worker process that runs that transform. The main point of
this is to handle cases where we interface with non-threadsafe code, and need
to isolate transforms in their own processes if we want to use multiple copies
of them.

Inter-process communication is handled using QLocalServer/QLocalSocket, the
actual worker processes are additional instance of br, which does mean this
bleeds out to the public API to an unfortunate extent.

Initial trvial tests seem promising, but generally we can expect performance
to degrade if larger amounts of data are transfered, ideally we should do
ProcessWrapper(Open+FeatureExtraction), so the data transfered to the worker
is an image name, and the data transfered from the worker is a feature vector.

This reverts commit 04105a9414fb68a95667812184e89cb937e858d5.

One way around issue #112

If we try to create a QApplication and fail, qt will call qFatal. We cannot
recover from that because even if we install a message handler, qt will still
quit regardless of what we do in that handler--qt will catch any exceptions we
throw, and there is no return value from the message handler.

The reason creating a QApplication will typically fail is if a window system
is not running, we may still be able to do something useful if we disable gui
support, so what we can do is start another br process with "-useGui 0" added
to the arugments (or otherwise we could start another process before trying to
create the QApplication, to see if QApplication is creatable).