Add simple CLI for ICA-based denoising

[tsalo]

I think we could have something extremely simple, like this:

ica_denoise \
    in_file \
    --prefix <prefix> \
    --mix <mixing_matrix> \
    --clf <component_table> \
    --method [aggr,nonaggr,orthaggr] \
    --dummy-scans <INT>

Users could pass in the mixing matrix and component table, and the output would just be the denoised version(s) of in_file. Output files would be named <prefix>_desc-<aggr|nonaggr|orthaggr>_bold.<nii.gz|dtseries.nii>.

I'm not sure if we'd want to support additional confounds as well.

[tsalo]

A few key points on this:

1. We wouldn't use an IOGenerator or load files based on the tedana directory. This would allow users to pass in specific mixing matrices and component tables.
2. The only column in the component table that it would use is classification, which should make it easier to use the CLI on non-tedana ICA derivatives.
3. in_file could be in any space, and could be a NIfTI or a CIFTI (or even a GIFTI I guess).

[handwerkerd]

I want to highlight that this is very similar to something we've talked about for a while. By adding the --tree option, this opens up our modularized decision tree code and provenance tracking for use in any mixing matrix based denoising method whether or not the data are multi-echo.

I'm fine with this & it wouldn't be too much work to create (famous last works), but it's not something I'll personally do until at least after OHBM.

As for how to approach this, from @tsalo's initial specification (without adding an option for --tree), this is nearly identical to ica_reclassify. The only changes would be:

• Giving an options to specify infile, --mix, and --component_table instead of registry.
• A state such that, when --manacc or --manreg are not supplied, it will still output the denoised data rather than an error. This state could be triggered with an additional parameter or by not providing registry
• I'd still want to use IOGenerator for the output & to create a registry for the output.

If we want to add an optional --tree parameter, then this would still be similar to ica_reclassify, but would have distinct functionality and would benefit from having a different workflow name. Thinking further, if this is modularized with this goal in mind, a modularized tedana workflow could call ica_denoise.