MAINT: Cleaning up dependencies

[oesteban]

• Remove unused MaskEPI interface (moved to niworkflows).
• Remove unused dependencies
• Alphabetical sort of dependencies

[auto-comment]

Thank your for raising your pull request.

Some of the fMRIPRep maintainers will review your changes as soon as time permits.
I'm attaching below a Review Checklist for the reviewers, to copy and paste
it in their review comment.

## PR Review

*Please check off boxes as applicable, and elaborate in comments below.  Your review is not limited to these topics, as described in the reviewer guide*

- [ ] As the reviewer I confirm that there are no conflicts of interest for me to review this work.

Please check what applies in the following aspects of the PR:

#### Code documentation

- [ ] New functions and modules are documented following the guidelines.
- [ ] Existing code required amendments in documentation and has been updated.
- [ ] Sufficient inline comments ensure readability by other contributors in the long term.

#### Documentation site

- [ ] The modifications to *fMRIPrep* in this PR **do not require extra documentation**. This is a common situation when a bug fix that does not change the code base substantially is submitted.
- [ ] This PR requires documentation. The corresponding documentation will be submitted as an additional PR in the future.
- [ ] This PR requires extra documentation, and will be included within this PR. Please check the boxes that apply best:
  - [ ] An existing feature is substantially modified, changing the interface and/or logic of a module.
  - [ ] A new feature is being added, therefore full documentation of it will be included
  - [ ] This PR addresses an error in existing documentation.
- [ ] Yes, all expected sections of documentation were generated by the CI build, and look as expected

#### Tests

- [ ] The new functionalities in this PR are covered by the existing tests
- [ ] New test batteries have been included with this PR

#### Data

- [ ] This PR does not require any additional data to be uploaded to OSF.
- [ ] This PR requires additional data for tests.

#### Dependencies: smriprep

- [ ] This PR does not require any update on `smriprep`; or
- [ ] `smriprep` has correctly been pinned.

#### Dependencies: niworkflows

- [ ] This PR does not require any update on `niworkflows`; or
- [ ] `niworkflows` has correctly been pinned.

#### Dependencies: sdcflows

- [ ] This PR does not require any update on `sdcflows`; or
- [ ] `sdcflows` has correctly been pinned.

#### Dependencies: Nipype

- [ ] This PR does not require any update on `nipype`; or
- [ ] `nipype` has correctly been pinned.

#### Dependencies: other

- [ ] This PR does not require any update on other dependencies; or
- [ ] other dependencies have correctly been pinned.

#### Reports generated within CI tests

- [ ] Yes, I have checked the reports of ds005 and they are not modified or the changes are as expected
- [ ] Yes, I have checked the reports of ds054 and they are not modified or the changes are as expected
- [ ] Yes, I have checked the reports of ds010 and they are not modified or the changes are as expected

### Review Comments (other than those left inline with the code)

[effigies]

scikit-image is causing problems in build_docs and from ...interfaces.nilearn import Merge in test_pytest.

[oesteban]

Yes, I've realized I can't just remove the module. I'll first migrate stuff to niworkflows and then come back to this.

[effigies]

Is it worth the effort to move more things to niworkflows right now? We've had a lot of API-breaking changes in our tangle of sub-packages that's already making it hard to keep everything in sync.

[oesteban]

Is it worth the effort to move more things to niworkflows right now? We've had a lot of API-breaking changes in our tangle of sub-packages that's already making it hard to keep everything in sync.

I've been thinking about this and:

• the migration seems pretty low-risk, we are porting a small section of code to niworkflows where these interfaces will be more exposed to additional uses
• I'm planning to release a niworkflows 1.0.0 sometime soon, I think this migration works well with the major release.
• If there is anything we test more thoroughly that is integration, so hopefully, that also plays in our favor making this little migration painless.

I hope I don't have to regret being writing this...

[effigies]

Okay. Just want to say that any change that doesn't happen directly in fMRIPrep seems to lead to cascading re-pins and compatibility updates, and hours of waiting on CI and bugfix releases delayed by days if not weeks. The more things we move outside of fMRIPrep, the more that condition will be hit, so I would strongly discourage moving things before there's a real need elsewhere.

I would like to find some point at which we dramatically slow down these refactors. We might need to put a dependency matrix somewhere so we know what minor versions each project depends on, and keep a maintenance branch for any minor series that is still depended on by a master branch somewhere downstream.

If you have a plan for niworkflows 1.0, that's fine. Just feeling like it's hard to keep up with all the moving parts, especially when trying to divide attention to other projects.

[oesteban]

Looking good - I'll merge this in and cut another rc soon to test more widely.