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.

Fuse updates

Resolved conflicts:
	app/br/br.cpp
	openbr/core/bee.cpp
	openbr/plugins/output.cpp

resolved conflicts:
	app/br/br.cpp
	openbr/core/bee.cpp
	openbr/core/classify.cpp
	openbr/core/cluster.cpp
	openbr/core/eval.h
	openbr/openbr.cpp
	openbr/openbr.h
	openbr/plugins/algorithms.cpp
	openbr/plugins/independent.cpp
	openbr/plugins/output.cpp
	openbr/plugins/svm.cpp

If just the first property name argument is specified, use that for both the
gt and predicted files.

Use empty strings to indicate when the gt/predicted property names are not
supplied to facilitate the above change.

Fix argument count checks for eval regression/classification.

Change default label name from Subjet to Label (since label is a more general
term).
Use different default variable names for classification (label), regression
(regressor/regressand), and clustering (ClusterID)
Update some (far from all) transforms to accept arguments specifying their
input/output variables.
Update eval classification to optionally take target variable names as
arguments

Remove global label/subject lookup table
Consistently use "Subject" rather than "Label", subject is assumed to be
convertable to QString. When desirable, map discrete subject values to ints.

For classifiers such as svm that require numeric labels, generate a string->int
mapping for the training data, and store it (local to the transform).

Utility functions for collecting all values of a given property (on a template
list), and mapping discrete property values to 0-based integers

Some outstanding issues include use of label/subject in matrix output

Remove subject/label methods from the API, replace some methods with general
methods taking a property name as an argument.

This breaks quite a few things