Pin mpl-sphinx-theme on the v3.7.x branch

[QuLogic]

PR Summary

A similar thing was done for the v3.6.x branch.

PR Checklist

Documentation and Tests

• [n/a] Has pytest style unit tests (and pytest passes)
• Documentation is sphinx and numpydoc compliant (the docs should build without error).
• [n/a] New plotting related features are documented with examples.

Release Notes

• [n/a] New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
• [n/a] API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
• [n/a] Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst

[tacaswell]

This should also go in the release guide updates?

[QuLogic]

Yes, probably; cc @ksunden

[ksunden]

Is there any reason not to pin this way on main? Its our own first party dependency that we control the release cycle of. While we currently version it for every (feature) release, it could in theory slow down that it doesn't need to be updated for each mpl release.

I feel like updating the pin is already a part of the theme release (we only updated it because we want to change/fix something, essentially), but changing it to ~= from >= doesn't change that procedure, and we pretty much always want to pin it to the most recent version.

If it is pinned on main, then there is nothing special to do for release, and just the repinning to newer versions doesn't get backported.

[tacaswell]

fair point. I am in general against hard pins, but this is in an internal requirements file we use for setting up CI + developers machines (not something carved into stone on pypi or a packaging system) so I guess that would be OK.