Sort out CoR estimation / class dispatch

In its current state, CoR estimation is a mess.

For the record:

• When building the ProcessConfig object, datasets estimations are done - this is "step 3" of ingesting the user configuration/dataset. ProcessConfig._get_cor() uses estimate_cor() from nabu.pipeline.estimators
• nabu.pipeline.estimators.estimate_cor() uses three "dispatcher classes": CORFinder, SinoCORFinder and CompositeCORFinder (all of them inherit from the same base class)
  • It's probably OK to regroup estimators depending on how they use the data (radios, sino, or radios + sino)
  • Can/should it be done otherwise ?
• The "near" handling in CORFinderBase could be improved
• Flat-field normalization might be simplified using the new readers
• How to deal with tilt when estimating CoR on a sinogram ?
• Once in (Sino)CORFinder, find_cor uses this unholy image-splitting scheme: shift = self.cor_finder.find_shift(img_1, np.fliplr(img_2), *self.cor_exec_args, **self.cor_exec_kwargs).
  • This is to mimic the interface of nabu.estimation.cor.CenterOfRotation.find_shift(), but these estimators are not alone anymore
• The dispatch is done in a quite abstruse way, using inspect. Instead, we should have a sequence of if method == "name": class_instance.entry_point(*exec_args, **exec_kwargs)