MNT: make layout deprecations pending

[jklymak]

PR Summary

Closes #22343

As noted there, deprecating immediately emits a DeprecationWarning, whereas this will emit a PendingDeprecationWarning.

PR Checklist

Tests and Styling

• Has pytest style unit tests (and pytest passes).
• Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

• New features are documented, with examples if plot related.
• New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
• API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
• Documentation is sphinx and numpydoc compliant (the docs should build without error).

[anntzer]

Thanks!

[timhoffm]

Should the api change now be adapted as well?

[jklymak]

Hmmm, I don't think I put in an API change note for the original deprecation, which was an oversight.

[jklymak]

So now that I think about this a bit more, do we really want to get rid of figure.set_tight_layout()? That is used massively in the wild.

[timhoffm]

I'd definitively get rid of get/set_constrained_layout_pads(). That's too specific for a figure method. But we're not in a hurry let's go an normal deprecation cycle here, including a pending round.

set_tight_layout/set_constrained_layout: In the very long run, we want to get rid of it because of the duplicate API. But there are 7.5k usages on GitHub, so I think a deprecation would be too annoying. I think we have to give a long lead to let it grow out to some extent.

• This should be marked as 'discouraged' like we did with figure(tight_layout=True).
• Maybe we want to set a PendingDeprecationWarning but without a timeline for the actual deprecation. The pending warning will usually only affect downstream libraries but not end-users. It's good if at least libraries have moved away from it, so that we can actually deprecate if we choose to without downstream libs annoying users with non-actionable deprecation warnings.

[jklymak]

OK, so left the pending deprecations in, but changed the deprecation note to say that set_tight/constrained_layout are discouraged rather than that they will be deprecated.