Fix and extend parallel_reduce functionality

[paciorek]

This addresses various aspects of parallel_reduce, with a fair amount of testing. I generally tried to work within the system, but there may be cases where @perrydv may think we should do it differently or at a different stage.

• This enables built-in reduction operators of +, *, pairmin, pairmax, with error trapping for use of other nCompiler operators.
• The init arg is now optional, and default values are built into the handler lists, via reduction = <some_init>. The existence of this is used for error trappling for valid reduction operators (perhaps this is trying to be too concise by combining the idea of a valid operator with the default init).
• The output type is determined from the type of the input vector (2nd arg). Perry's original code used the type of the init value. And Perry and Chris discussed generating dummy code: reduction_op(x,y) to determine type, but it seemed most natural to me to use the type of the vector.
• User-defined reduction operators now work when provided as nFunctions (but not as other methods of the same class [see issue 133]). If no init is provided by the user we error trap. I have not tested having a user-defined operator in which the default init is provided.
• I've added some additional checking for uncompiled execution but there are problably corner cases.
• Inf and negative values for initial value now works.
• A user can provide the user-defined reduction function either as a char or as a function. In principle this would be fine for non-user-defined but there are no R pairmin/pairmax functions.
• Some work was needed to fix up C++ generation of the join for various situations.
• Use of parallel_reduce in a standalone nFunction is trapped, but in an awkward stage and awkward way.

The following are still issues:

• Using a method of another class as the reduction operator does not work.
• For min/max, one needs to use pair{min,max} as these are the actual relevant binary operators. We should discuss if we want to automatically convert {min,max} to these for the user.
• Per issue using expressions as the input vector in parallel_reduce #137 , using an expression as the input vector does not work.
• Per issue type awkwardness with parallel_reduce #136 there are still some type issues when using integer types.
• Should we rename to parallelReduce for consistency with other user-facing naming?