ENH: Switch to the refactored report generation from NiWorkflows

[oesteban]

In preparation for #1596 and #1586, this PR fully migrates fMRIPrep's generation of reports to NiWorkflows.

A side work stripping out some sentry tracking of errors from the generation function was necessary. The idea would be to keep cleaning up the run.py script from sentry tracking by moving more functions to fmriprep/utils/sentry.py.

[oesteban]

This PR splits some of the changes of #1596, so that one can be reviewed after this is merged to only show changes that pertain to the new --output-spaces argument.

[effigies]

I assume a CircleCI build should show up?

[oesteban]

Yep, it should - https://circleci.com/workflow-run/f9a5dfd6-a0c6-4e53-8924-ee81fef969b6

[effigies]

Cool. I'll wait on that to review.

[oesteban]

Okay, this seems to be getting closer. Please notice that ds005 is generating a T1w-to-MNI152NLin6Asym that is not supposed to appear. I think it comes from ICA-AROMA? I'll let you know when I find out.

[effigies]

@oesteban I can't restart the failed job because it's under your user in Circle.

[oesteban]

I'll try to get back at this. I found out that it is 99% sure an old reportlet perpetuating under work/reportlets. I've cleaned up the cache and now I delete the reportlets folder after the anatomical workflow.

However, the job would not run now. I think in part because of #1602 as the anatomical work dir is not being reused.

[oesteban]

Actually, I'm wrong: in the cleanup I mistakenly included the freesurfer dir for deletion. Fixing that now.

[oesteban]

Thanks for #1602, this build should be the one.

[oesteban]

@effigies green lights! at last!

[effigies]

Looks fine. So niworkflows is now hosting fMRIPrep's report configuration YAML? It seems like it makes more sense here.

[oesteban]

I agree we will eventually want to get the control over the config file back to fMRIPrep. However, I would keep the fmriprep.yml file as the base exemplar in Niworkflows.

Given that such a config file does not change a lot through history, I'd say to keep it in niworkflows for now and move it over here when necessary.

In theory, generate_report should keep working with user-supplied config files. That is not currently tested. What I'm trying to say is that everything should be in place for us to move the config file here when we want.

I'll go ahead and merge this in.