Qt bindings mutex?

### Your question:

Hey everyone, I'd like to discuss the possibility of adding a `qt_bindings_mutex` package to conda-forge, similar to what we do with BLAS, MPI and others.

`qt` can be used from Python via two different bindings: `pyqt` (GPL) and `pyside` (LGPL). A Python interpreter process can only use one of them at a time, as far as I know. There are some wrappers (e.g. `qtpy`) that abstract away the differences between the two bindings, so developers can target both with a single codebase.

`qtpy` allows [choosing the backend via `QT_API`](https://github.com/spyder-ide/qtpy#requirements). Since you can choose, `qtpy` does not depend on either `pyqt` or `pyside`. Still, one of them is needed, so maintainers usually add `pyqt` next to it. There are [47 recipes](https://cs.github.com/?scopeName=All+repos&scope=&q=org%3Aconda-forge+pyqt+qtpy+path%3Ameta.yaml) that rely on both pyqt and qtpy, which means that they could possibly work with pyside right now, but `pyqt` is being chosen regardless. Conversely, only [15 results show up](https://cs.github.com/?scopeName=All+repos&scope=&q=org%3Aconda-forge+pyside2+qtpy+path%3Ameta.yaml) if we query for `pyside2` and `qtpy`.

Right now, `napari` is distributed with [two variants](https://github.com/conda-forge/napari-feedstock/blob/12bd11f0f28001cd4cc2c74c3abe604f2e5bfcca/recipe/meta.yaml#L82-L84) to cater this use case. However, this does not prevent pyqt and pyside from being co-installed. We are considering adding `run_constrained` metadata to prevent this, but given the amount of packages that decided to depend on `pyqt` by default, this might introduce solving conflicts (when they shouldn't be any because `qtpy` is supposed to make projects bindings agnostic!).

So my question is the following: would it make sense to have a `qt_bindings_mutex` to implement this option conda-forge wide? That way, recipes that rely on `qtpy` (or similar) can simply add the mutex as the dependency, and end-users can choose which one should be installed?