py-pyqt5: fix DBus module build and pyversion conflicts, support multiple Qt5 ports

[RJVB (René Bertin)]

This patch addresses a few issues with the new port:py-pyqt5:

• the DBus component wouldn't build because the dbus-python.h (or else the dbus.h) headerfile wasn't found

• QtWebEngine is a huge component which is currently used by only (very) software projects and probably even less ports. It is not installed by default by the port:qt5 metaport, nor by my own port:qt5-kde. Therefore, I suggest building it via a variant (which can become a default variant once QtWebEngine gains traction).

• the Designer and QML plugins do not carry Python version information in their name, causing installation conflicts between py27-pyqt5, py34-pyqt5 and py35-pyqt5. The configure script has--designer-plugindir and --qml-plugindir options (probably for exactly this reason) that allow to avoid such conflicts. I have not yet tested whether this is completely transparent under normal use.

• the Python PortGroup contains code which overrides the dependency information set by the Qt5 PortGroup. This will become an issue when my port:qt5-kdeis committed (which is intended to be a drop-in replacement for users accepting to build ports that don't prefer it from source). I have submitted a convenience procedure to be added to the Qt5 PortGroup (#51619) which hides the details of setting up the appropriate Qt5 dependencies; a simple qt5.depends_component qt5 will pull in port:qt5 (or port:qt5-kde) and the optional qt5.depends_component qtwebengine will pull in the corresponding QtWebEngine subport.

Until that procedure is added to the Qt5 PortGroup it will of course be defined locally...

[mojca (Mojca Miklavec)]

See also #52500.

[RJVB (René Bertin)]

Here's the new patch announced on #52500. It looks more complex than it is because I couldn't resist cleaning up whitespace inconsistencies too.

Compared to my original submission, this patch drops the qt{webkit,webengine} variants which were already implemented under a shorter name, but also reverts to NOT making the QtWebEngine variant default. That Qt component is huge as said and not yet used by many ports, so I consider it still justified to make it available on explicit demand only.

I have implemented an additional variant the interest of which became apparent while using the software. It prevents aborting (= on-demand crashing) when Python errors (even benign ones) occur.

[mkae (Marko Käning)]

In d4bfb294/macports-ports:

py-pyqt5: fix DBus module build and pyversion conflicts

• also support multiple Qt5 ports
• remove invalid keyword 'Id'

Closes: #51620

[mkae (Marko Käning)]

In 0229294a/macports-ports:

py-pyqt5: fix DBus module build and pyversion conflicts

• also support multiple Qt5 ports
• remove invalid keyword 'Id'

Closes: #51620