feat: XYShift block for translation transform

[schackey]

Description

Re-integration of the XYShift alignment method.

Related Issue

In the new version, the default alignment was done by 'AlignReferenceSources()', which used twirl. After discussion, Lionel suggested to reintegrate the simple XYShift algorithm as most tracking issues are translational.

Type of Change

I integrated a boolean parameter 'XYShift' in the 'AlignReferenceSources()' block. Furthermore, I expanded the 'ComputeTransform' block into two new blocks: first I duplicated the block and called it 'ComputeTransformTwirl' and then I reimplemented the XYShift block from an earlier version as the 'ComputeTransformXYShift' block. By default the parameter 'XYShift' is set to False, and so by default twirl is used for alignment, as is done in ver 3.0.0.
I have tested the algorithm on a few example dates, by visually checking the resulting stack and it shows no streaks and other features indicating that alignment would have failed. However, proper testing has not been done yet.

Checklist

• I've read the CODE_OF_CONDUCT.md document.
• I've read the CONTRIBUTING.md guide.
• I've updated the code style using black.
• I've written tests for all new methods and classes that I created.
• I've written the docstring in numpy style for all the methods and classes that I used.

[lgrcia]

Thanks a lot for these additions @schackey. I will create an alignment test based on fake sources and merge if passing.

[lgrcia]

Hi @schackey. Could you think of a test function for these additions?

It could be done on two images, one with fake sources and the other with the same sources but transformed with a known transform. Then we should be able to find the known transform using both of the ComputeTransform blocks you implemented.

Can you also ensure that the AlignReferenceSources is not computing the transform anymore?

Edit: I wrote the transform test in 52f8348