Feature: JointIterativeClosestPoint

When doing, e.g., extrinsic calibration between two sensors, it's common to want to leverage multiple observations and solve for a single global transform. @JointIterativeClosestPoint@ implements a very generic version of that. It uses the @IterativeClosestPoint@ framework, but allows for multiple pairs of Source/Target clouds to be given. It then uses the given @CorrespondenceEstimation@ methods to compute correspondences separately, but solves for a global transform.

A few things which would still be nice:
* As referenced in other issues, our CorrespondenceRejector class doesn't currently expose any sort of virtual "addInputSource/Target" functionality. So there's no way to do that generically here. For any data-driven rejector (just about all of them?), this method probably won't work.
* It'd be great to have generic cloning functionality for CorrespondenceEstimators. Then a user could simply set one, and I'd clone it for all pairs of clouds. Currently it either requires the user to manually set a separate one for each, or uses one default method.
* To keep the API the same, I still have it return an output cloud (empty), and use aggregated versions of the source and target clouds for @Registration@-level calls, like @computeFitness@. This could be handled more nicely.