This is WIP to move IPython's backend mapping into Matplotlib andextends it to allow backends to register themselves via [entrypoints](https://setuptools.pypa.io/en/latest/userguide/entry_point.html#entry-points-for-plugins).It is a coordinated effort across Matplotlib, IPython, matplotlib-inlineand ipympl.Closes#14311. Most of the work is in Matplotlib(matplotlib/matplotlib#27948) but I will repeat the relevant pointshere.When using a Matplotlib magic command of the form `%matplotlibsomething` the identification of the Matplotlib backend and GUI loop arenow performed in Matplotlib not IPython. This supports:1. Matplotlib backends that IPython already supports such as `qtagg` and`tkagg`.2. Other built-in Matplotlib backends such as `qtcairo`.3. Backends that use `module://something` syntax such as`module://mplcairo.qt`.4. Backends that self-register using entry points, currently `inline`and `widget`/`ipympl`.Implementation details:1. The magic command is now explicitly `%matplotlib gui_or_backend`rather than `%matplotlib gui`. This is already effectively the case ase.g. `%matplotlib ipympl` is really a backend not GUI name. WithinMatplotlib the `gui_or_backend` is checked first to see if it is a GUIname and then falls back to checking if it is a backend name.2. If you select the `inline` backend the corresponding GUI is now`None` not `inline`. All backends which do not have a GUI loop return`None`, otherwise we have to keep explicit checks within IPython forparticular backends.3. `backends` and `backend2gui` are now deprecated but are stillexposed, with a deprecation warning, if required. If using Matplotlib,ipympl, etc releases that include the corresponding changes to this PRthen they are not needed as Matplotlib deals with it all. But forbackward compatibility they must still be available for a while alongwith the remainder of the existing backend-handling code.4. I haven't yet updated the documentation but we need to keepinformation about valid GUI frameworks and I propose that we shouldremove all lists of valid Matplotlib backends, replacing them withinstructions on how to obtain the current list (pointing to theMatplotlib docs and using `%matplotlib --list`). If we keep any liststhen they will inevitably become out of date. This extends to the`backend_keys` in IPython/core/shellapp.py.Because the four related projects are loosely coupled without directdependencies on each other (except for `ipython` and`matplotlib-inline`), backward compatibility requires all possiblecombinations of projects before and after the new functionality (I willcall these "old" and "new" from now on) to continue to work. I havetested these all locally, and the CI of this PR will test new IPythonagainst old Matplotlib for example, but I need to add one or more newtemporary CI runs to test new IPython against new Matplotlib etc. Theidentification of new versus old depends on version checks on the otherlibraries, so here is a table that I will update showing the currentstatus of progress in the 4 projects:| Project | Relevant PRs | Possible release version || --- | --- | --- || matplotlib-inline |ipython/matplotlib-inline#34,ipython/matplotlib-inline#35 | 0.1.7 || ipympl |matplotlib/ipympl#549 | 0.9.4 || Matplotlib |matplotlib/matplotlib#27948 | 3.9.1 || IPython |#14371 (this) | 8.24.0 |The two widget projects can be released soon, once we are happy with theentry point approach. The other two projects' PRs will have to besynchronised as each includes version checks on each other.To do- [ ] Add CI runs against the new PR branches of the other projects.- [ ] Add comments for conditions required for backward-compatibilitycode blocks to be removed.- [ ] Update documentation, including removal of lists of validbackends.- [ ] Update version checks before merging.

Fixes#14401 which has been a bug in the 8.22.x and 8.23.x releases.When I removed the multiple initialisation of Matplotlib backends in#14330 it broke use of the following:```bashipython --matplotlibipython --matplotlib=autoipython --pylabipython --pylab=auto```by failing to display Matplotlib plot. If you specify a particular GUIevent loop such as using```bashipython --pylab=qt```then it was and is fine. So for anyone finding this, the workarounduntil the next release is to specify a GUI loop rather than relying onthe auto selection.I didn't notice this as I've been concentrating on moving the Matplotlibbackend logic from IPython to Matplotlib, and with those changes(matplotlib/matplotlib#27948) the above use cases all work OK.The fix is to reintroduce the early import of `matplotlib-inline` butonly if both the gui loop is not specified and the Matplotlib version isbefore the movement of the backend logic across to it.There are no explicit tests for this. In the future I will try to thinkof some tests for some of this IPython-Matplotlib functionality thatdon't involve installing complicated backend dependencies or addingimage comparison tests.

…lib and support entry points

…948-on-v3.9.xBackport PR#27948 on branch v3.9.x (Move IPython backend mapping to Matplotlib and support entry points)

This is a correction to the code that moves backend handling toMatplotlib, which came to light during the review ofmatplotlib/matplotlib#27948. The GUI framework of macOSX is called `osx`in IPython but `macosx` in Matplotlib.It would be possible to allow passing a GUI framework of `osx` toMatplotlib and internally converting it to `macosx`, but the reversedirection is problematic as we would like the answer to be `osx` if weare using IPython and `macosx` if using pure Matplotlib. Therefore thesimplest solution is to do the translation in IPython. It is not idealas we want to minimise such Matplotlib-related implementation details inIPython, but the changes here are small and simple and hence I thinkthey are acceptable.There are two new private functions `_convert_gui_to_matplotlib` and`_convert_gui_from_matplotlib` to do the required checking andconversion, and these are called whenever a GUI framework name is passedto or from Matplotlib. There are only 3 places in the code where this iscurrently required.Inevitably this comes to light just after the release of IPython 8.24.0!But it is not a problem for end users until the next Matplotlib releasewhich containsmatplotlib/matplotlib#27948. If that occurs reallyquickly (sometime in May?) perhaps we could release an IPython 8.24.1just beforehand, otherwise the usual planned release at the end of nextmonth would be fine.