Merge SHARDRecon into main MRtrix3 codebase

I'm going to generate a list here of things that come to mind; nothing major, just thoughts that I think are worth contemplating. Don't want to block progress by demanding massive pieces of work, just starting dialogues. Some I can help out with.

[ ] dwirecon command (#2915 relevant): At the moment this is hard-coded to yield multi-shell spherical harmonics data, however from the command name one would intuitively expect DWI data. There's a few different options here, and it might need a combination of things to get fully resolved with #2915:
- Change name of this command to msshrecon. Completely unblocks #2915.
- Make dwirecon an operation-based command. Essentially take what's in #2915 and make what is contained within cmd/dwirecon.cpp in this PR another operation within that command, with a set of command-line options that are applicable only to that operation.
- Have a toggle that changes the output of this code between multi-shell spherical harmonics and reconstructed DWI data. (I would possibly lean towards a toggle here, rather than having a default output and then a command-line option that outputs the data in the other form, since it's large data and users are likely to want one or the other)
[ ] Data type for command naming: Currently here "mssh" is used for multi-shell spherical harmonics. I am however reminded that dwi2fod msmt_csd started its life as msdwi2fod. Here there is a stronger argument for a different datatype indicator: mssh and sh are less interchangeable from a data description perspective that single-shell vs. multi-shell DWI data. It may however be the case that many operations intended for SH data can be extended to multi-shell SH data.
- Possibility of just using sh from a command name perspective, and anything that expects multi-shell SH but receives a single SH, or vice versa, throws an Exception? Whether this might be reasonable would require looking across the package for SH interfaces.
- Is mssh the best indicator? Would "multi-spherical-harmonics (msh)" work? Are there any contexts in which one may have multiple spherical harmonics functions, where the groups of coefficients do not correspond to shells? Multiple ODFs within a single 5D image comes to mind. I suppose shard isn't correct from a data description perspective?
[ ] dwirecon needs a more comprehensive Description.
[ ] I'd like for there to be more explanation of how the slice profile is derived / interfaced so that I can try to make proper use of it for my own data.
[ ] I know that for my own data, having the ability to correct for eddy current distortions is going to be important. I tried to read up on the Lie algebra used for the motion modeling, but it's well outside my current expertise to know how it might be extended from rigid-body to an affine model, or what the consequences of doing so on other code might be. @dchristiaens Do you have an intuition of how involved such a change might be? I'm happy to help on this one where I can from a code perspective , I'm moreso doubtful on my capacity to derive / follow the math.
[ ] Some commands involve specification of multi-band factors to influence slice-to-volume registration. This could be streamlined by instead making use of SliceTiming.
[ ] With mrfieldunwarp, I'm wondering if this could be handled differently. If one has a susceptibility field in Hz, then that can be converted to a deformation field based on phase encoding direction & readout time. That's just a non-linear warp field that can be composed with any other transformation, whether it be rigid-body motion (as `mrfieldunwarp currently handles on a per-slice-stack basis) or anything else (eg. I'm imagining composing this with the gradient non-linearity geometric distortion field). Therefore, is this something that could be adequately handled by:
- Giving warpconvert the ability to convert inhomogeneity field to deformation field based on phase encoding information
- Having some other way to compose this deformation with per-slice-stack motion parameters ? It's not immediately clicking what the best form of the second point would be. Explicitly composing transforms and then subsequently applying those transforms would be the most modular, but highly inefficient. Maybe if mrtransform could accept both the deformation field and the rigid-body motion parameters and would then be responsible for the composition?
[ ] @dchristiaens Are you able to share some exemplar data for which you know the reconstruction pipeline behaves properly and yields an acceptable result, whether privately or publicly? Just if I'm going to muck around with the code I'd like to know that I'm not breaking anything. (If I do come up with any changes, I won't commit directly to this branch, I'll make a PR)
[ ] Some Python commands need to have their typed arguments updated.
[ ] Python commands using 4 spaces for indentation, whereas the internal convention is 2.
[ ] Some Python code could make better use of F-strings, which are now used throughout the Python code base.
[ ] File copyright headers currently differ from the main code base.

MRtrix3 / mrtrix3

Merge SHARDRecon into main MRtrix3 codebase #2994