Distance gallery and output incremental operations from Globals->blockSize

For galleries, add a property to Gallery indicating the number of templates
that will be read per block (for galleries that do incremental reads--really
just galGallery and memGallery).

For outputs, add two properties indicating the rows and columns of blocks to
use (i.e. support non-square output blocks).

For both classes, default these properties to Globals->blockSize
Add a mode for stream that assumes input templates are galleries, and reads all available frames from them
Modifications to  GalleryCompareTransform

Take an algorithm description as input for the distance, ideally we would
support inputting an algorithm or just a distance string, but currently that
seems infeasible (no recovery if we fail to create something).
Add a transfrom interface to Output

OutputTransform takes inputs suitable for an output (Output specification,
target adn query galleries), and expects to receive rows of a comparison matrix
on incoming templates.

OutputTransform supports receiving either rows one at a time, or columsn one at
a time (via the transposeMode flag).
Support for an alternate version of compare

Adds an emptyRead method that reads just the metadata from a gallery and drops
the matrices.
Modify pairwiseCompare to set blockSize directly on its output rather than
messing with Globals->blockSize

Add an alternate version of compare, which defines the comparison through the
Transform hierarchy rather than using distance directly.
Add explicit multi-process support to enroll and altCompare, some bug fixes

Add explicit multi-process support to enroll and compare, if -multiProcess true
is specified, ProcessWrapper will be attached to the current algorithm in
enrollment and comparison (causing the job to be distributed over multiple
br processes instead of using multi-threading).

This is desirable since putting ProcessWrapper directly on algorithms leads to
some compositionality problems (it's very undesirable to have nested process
wrappers).

One drawback is that in multi-process mode, altcompare has to write the
explicitly enrolled gallery to a file (instead of using a memGallery) since the
slave processes obviously don't have a shared memory space. A better approach
might be to have processWrapper serialize and transmit its transform (instead
of constructing it), but even that won't work directly since transforms often
rely on reconstructing data from other files even if serialized.
Explicitly replace AlgorithmCore::compare with the new version of compare
Merge pull request #165 from biometrics/alt_compare

Compare changes