refs #9257. Make integration thread safe.

A very simple solution to a threading issue. We can safely process the
peaks list in parallel if the integration can be guaranteed to be thread
safe. By making the interation a const member that simply returns the
results we do this. Therefore concurrent thread access will cause no side
effects. This Will allow us to handle the case where the user has selected
a threshold such that two peaks end up sitting on the same cluster and
therefore the integration method could be entered simultaneously.
Functional programming had the solution.

Also, I've made some changes to reduce the amount of work happening to
determine the Clusters which are unresolved. I can avoid this duplication
because for each indexpair that gets registered, there will always be a
duplicate (there has to be as each unreachable neighbour for one process
index is itself an unreachable neighbour for another process index) and
therfore only one cluster needs to be entered into the vector.
refs #9257. Do writeTo in parallel.
refs #9257. Extend tests for cluster type.
refs #9257. No need to specify the radius any more.

Part of the speedup is removing the PeakBackground strategy for the
simplier Hard threshold. We also have no need to use the radius. This is
nicer as we just let the algorithm figure out the integrated region
associated with a peak with minimal help (other than the threshold of
course).