enabling multithreading in broadcast_reduce

[asmushetzel]

Description

Add multithreading on CPU for the class of broadcast_reduce operators. For unknown reasons, this class of operators does not use any internal threading so far and therefore was observed to become a serious runtime bottleneck in an application. Threading is done on the level of sequences to be reduced, not within a single reduce sequence. This pattern is in line with the one that we are already doing in elemwise_binary_broadcast_op.h (where we achieve threading when starting the binary_broadcast_kernel).
With this change, this class of operators shows good threading whenever we reduce over multiple sequences and matches the runtime characteristics of elemwise_binary_broadcast.

Checklist

Essentials

• [x ] Passed code style checking (make lint)
• [x ] Changes are complete (i.e. I finished coding on this PR)
• [ x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

[piiswrong]

LGTM.

FYI, the speed of broadcast reduce can be further increased (5x ~ 10x factor) if it uses LaunchEx
23a9294#diff-c7d5e7c79e0ac86ec5544f46ebafe1c4R176

I only did it for binary_broadcast. You are welcome to contribute to the other parts if you want

[asmushetzel]

Will follow that pattern in order to make things consistent.
But not clear to me why the implementation in binary_broadcast should be that much faster (on CPU at least). Can you give some explanations?