Use specific nilearn version for building all docs

[rob-luke]

Reference issue

In #433 the version of nilearn used in the CI was updated to be the main branch and examples and code were changed to work with breaking changes in nilearn 0.9. However, old versions of MNE-NIRS do not work with this nilearn 0.9.

The doc system for MNE-NIRS builds the docs for all versions of the software when a change is made to main. However, all versions are built with the same dependencies. So, due to the change in #433 all previous versions of MNE-NIRS documentation are not building.

The reason all versions of the docs are built each time is so that the banners pointing you to the latest version are updated and so is the version dropdowns etc.

What does this implement/fix?

This PR changes the version of nilearn that the docs are built with to be the last release version. All versions of MNE-NIRS should work with nilearn 0.8.1

Additional information

This is not a sustainable change. I see a few options moving forward

1. Find a way to build the docs for each previous mne-nirs release with the dependencies at the time (I cant see how this could be possible).
2. Only build the latest version of the docs (this will break banners and dropdowns)
3. Remove docs for versions of MNE-NIRS older than the current dev
4. ????

Thoughts @larsoner ?

[larsoner]

Only build the latest version of the docs (this will break banners and dropdowns)

This is what we do for MNE-Python, and in the end they end up not broken but just a bit deficient (in an acceptable way I think). The process is basically the following, assuming you are releasing 0.3 (meaning you already have a docs page with a dropdown for v0.1, stable, and dev):

1. On the gh-pages branch (mne-tools.github.io repo for us), git cp -a stable v0.2
2. Push a commit to main to change the version number to 0.3.0 and update the banner HTML to have v0.1, v0.2, stable, and dev entries (note the v0.2 is the new one here), update CircleCI config to upload maint/0.2 as stable, and branch to a new maint/0.3 branch and push. After a couple hours, a new stable directory is created by CircleCI
3. Cut the release
4. On main, change the version to 0.4.0.dev0, which after a few hours will update dev

At this point you end up with a structure where stable and dev have all entries -- but the one real drawback is that something like 0.1 will only have "stable" and "dev". But really this seems like an unimportant missing feature, since it's clear you're on an old version and we have a banner that yells at you to tell you this (i.e., the 0.16+ are all missing from the upper-right banner here, but it doesn't really matter IMO based on the clear visibility of the banner saying "you're on an old version, look at the newest one"), and the only thing you should care about really is stable and dev:

https://mne.tools/0.15/index.html

Because the "newest one" is always available at stable, this can point to the same place on all versions of the HTML. If someone really wants v0.2 and somehow ends up on the v0.1 page and can't get to it (which is probably exceedingly rare!), it's still easy enough for them to get to v0.2 via two clicks (first to get to the latest stable or dev docs, second to use the drop-down to select v0.2).

We have been doing it this way for years, and it only creates a small, tolerable amount of work at release time. And we only ever need to worry about making sure doc builds ever work for the stable and dev at the time, not older versions. This is in line with our dev model, which only provides/claims support for the latest stable version.

[larsoner]

... doing what MNE-Python does would also allow you to kill all the sphinx-multiversion stuff, which I think is a maintainability gain