Deprecate the backend.qt{4,5} rcParams.

[anntzer]

1. For the rcParams rewrite (MEP32), they may make it tricky to
   transform rcParams into a nested dictionary type of object, as "backend"
   is already the name of another (more important) rcParam.
   (I haven't decided on a nested dict design yet, just keeping options open.)
   This specific issue could be solved with deprecation + renaming, but also...

2. The use of these rcParams can easily be replaced by a) first
   importing one of the bindings (qt_compat will ensure that the already
   imported binding gets used, as importing multiple bindings in the same
   process is a bad idea anyways), or b) setting the QT_API environment
   variable appropriately.

Milestoning as 2.2 so that the rcparams may actually get removed when (if) MEP32 makes it in 3.0, but feel free to push back too.

PR Summary

PR Checklist

• Has Pytest style unit tests
• Code is PEP 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

[jklymak]

So, is an alternative to make new rcParams that do the same thing? I don't use these rcParams, but maybe some people do. I'm not sure about the goal here other than an rcParams namespace issue?

[anntzer]

Renaming would be the other option, but again I think QT_API or preimporting either module is good enough. Of course, we'll see how much pushback we get after releasing this...

[jklymak]

I'm fine w/ this, but maybe there is a large audience who uses these rcParams...

[jklymak]

OK, maybe I made a mistake approving this.

On master, with no matplotlibrc file (i.e. using the defaults), I get both these deprecation warnings, which is super annoying.

I think somehow if the user does not specify these parameters, they should not still get a warning!