The current implementation of bbox_inches="tight" is to no-output-draw
the figure, compute a tight bbox, and then shift all artists to their
"new" position in tight-bbox-coordinates, draw, and shift back -- which
causes all kinds of grief (especially for @jklymak :-)); see e.g. #19832
for a recent case.

Instead, we can perform the real draw the first time, and then crop the
resulting image (either actually crop it for raster backends, or just
adjust the viewport for vector ones).

This PR is a proof-of-concept for such an approach (tests fail, that's
expected). Currently it writes the first file to the filesystem and
then edits it; likely the first file should be just kept in memory
instead (after all the final output could also just be an in-memory
buffer). This would also avoid having to dupe the metadata handling
(for agg).

Perhaps the method should be on the renderer instead (the exact API is
needs to be discussed). Extra points if the API is designed in such a
way that mplcairo can directly call into it.

Currently not implemented for postscript because bbox_inches="tight"
doesn't work there anyways (although we should fix it for postscript)
(#16657 is related). Not sure about pgf output, but that's probably
workable...

Final version should keep some backcompat layer, not present here to
improve readability.

Note for myself: https://tex.stackexchange.com/questions/307797/how-to-measure-the-height-of-a-tikz-picture
likely provides a way to implement this for pgf.

See #20250 for a possible alternate approach.

PR Summary

PR Checklist

• Has pytest style unit tests (and pytest passes).
• Is Flake 8 compliant (run flake8 on changed files to check).
• New features are documented, with examples if plot related.
• Documentation is sphinx and numpydoc compliant (the docs should build without error).
• Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
• 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).