As argued elsewhere, a customization point which requires third-party
libraries to override a private method is awkward from the PoV of
documentation and of required API stability. In fact _init_toolbar is
not needed as a customization point; third-party libraries can simply
override __init__ and call super().__init__ as appropriate.

Moreover, requiring that _init_toolbar be overridden is actually
overkill, e.g. for test_backend_bases.py::test_interactive_zoom:
there, the base class NavigationToolbar2 is perfectly suitable -- see
change there.

In order to let third-parties write code that supports both pre- and
post-deprecation versions of mpl, allow them to keep a fully empty
_init_toolbar (an override is required by earlier versions of mpl)
without triggering a deprecation warning.

Note that git(hub) may show the diff a bit weirdly, but for the GUI backend implementations, this is basically just moving the body of _init_toolbar into __init__ (it's just that git instead shows that as the code between __init__ and _init_toolbar moving down.)

PR Summary

PR Checklist

• Has Pytest style unit tests
• Code is Flake 8 compliant
• New features are documented, with examples if plot related
• Documentation is sphinx and numpydoc compliant
• Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way