ML norm code should work by bucket, not by block

[KrisThielemans]

As found by @nikefth, @francescaleek and @emikhaylova, the current assumption behind symmetries in find_ML_normfactors3D that the scanner is invariant over rotations by block is often incorrect in practice. Most scanners will have a few blocks in a "bucket", and the rotational (and for some scanners even axial translation) symmetry should be applied on the bucket level.

If the symmetries are wrong, @francescaleek found that the patterns in the estimated geometric factors will incorrect (mostly underestimated).

[robbietuk]

Some comments:

• ML norm code currently uses num_crystals_per_block, it should use num_crystals_per_bucket instead
• The handling of virtual crystals in a block/bucket configuration might take some thinking about.
  • Both in trans-axial and axial directions

[robbietuk]

I have given this a shot and while I thought it would be nice and easy, there are ~180 uses of foobar_per_block mentions that simply need to be replaced with foobar_per_bucket. Therefore, I will wait for #833 to be merged before I fix this problem otherwise the conflicts will be significant and confusing

[KrisThielemans]

940 solves this without the renaming. That still needs to be done.

[KrisThielemans]

re-opened such that we don't forget to rename all the internal functions