New command dwi2noise

[Lestropie]

Strongly related to #2274.

In the scenario where one fully intends to perform a two-pass operation, one to estimate the noise level and then one to denoise based on a (possibly filtered in an intermediate phase) noise level input map, it would be wasteful to necessitate use of the dwidenoise command for the first step. It would involve reconstructing and writing a denoised DWI series that is to be discarded. Further, there are likely a few command-line options for dwidenoise that would be entirely inapplicable for the first step.

What I'd like to do is move much of the denoising code into src/, and then have two commands, dwi2noise and dwidenoise. The former would be constrained to noise level estimation and exporting of features such as rank. For the second, the noise level for denoising would either be provided via command-line option, or operate using the same mechanism as dwi2noise if not provided.

[Lestropie]

@tsalo Regarding the NORDIC approach of estimating the noise level via no-RF volumes as mentioned in nipreps/fmriprep#3395:

There's already a bit of a misnomer here, the existing dwidenoise command technically doesn't operate exclusively on DWI data as one would expect given the name (which we've been quite pedantic about elsewhere). I think we can nevertheless extend that naming to a dwi2noise in the case where the same PCA-based noise level estimation is happening. However for utilisation of the no-RF volumes for noise level estimation it's probably straying too far away from a "this command operates on DWI data" label. So it might warrant a different command.

Do you have any capability for contributing toward such? I've never seen or acquired no-RF volumes, so don't have any particular vested interest in it, and I've suddenly generated a whole lot of other changes I'd like to make to denoising (#3023); but if there's anyone interested in taking it on I'm happy to assist in doing so within the MRtrix3 API to keep it all together.