Peter M. Groen / openbr

In a shocking turn of events, Qt is annoying, and not particularly
consistent across platforms.

Lot of not particularly intelligent business with signals to get things to
execute on the main thread.
I would rather not even use the event driven interfaces to
QLocalServer/QLocalSocket but sadly it seems that on windows even if we
try and use the blocking calls, we are still required to use using exactly one
thread per object. Of course that makes sense since obviously we are writing
a simple event-driven GUI application.

Add a wrapper transform that runs a child transform in a separate process

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.

Decouple variantlist

Conflicts:
	openbr/core/qtutils.cpp
	openbr/plugins/landmarks.cpp

This reverts commit 04105a9414fb68a95667812184e89cb937e858d5.