Flip the Qt 6 switch

[The-Compiler]

• Enable autoselection for QUTE_QT_WRAPPER, so that PyQt6 is preferred, and we fall back to PyQt5 if it is unavailable
• Replace _DEFAULT_WRAPPER in machinery.py with a _WRAPPER_OVERRIDE (cc @ionenwks)
• Switch most tooling (everything except mypy?) to Qt 6 by default, so that ...-qt5 is the Qt 5 variant, and no suffix is Qt 6
• Provide both PyQt5 and PyQt6 to pylint, which seems to teach it to check things with basically an union of PyQt5 and PyQt6

Will be merged once Qt 6.5.2 is out due to various regressions in Qt 6.5.1. That's planned to happen on Wednesday. With a few days until Archlinux/Gentoo have updated their Qt packages hopefully, I'm aiming to merge this in early July.

As for distributions:

• Archlinux is definitely worth waiting for - they are usually fast, and most of the userbase is there
• Gentoo already defaults to Qt 6 for git anyways
• Any other distributions with a git qutebrowser package?

The unstable-qt6 docker environment fails because the image isn't pushed yet. Will need merge to master first, as it gets only pushed there.

Closes #7202 (finally!).

[toofar]

Yay! 👏

Will be merged once Qt 6.5.2 is out

Hmm, I was thinking there might be something in the autoselect logic to only auto-switch to Qt6 on 6.5.2+, do you think there is any need for that?

[The-Compiler]

Welp, I just noticed some of scripts/ and all of misc/userscripts are still both Qt 5.

For the latter, I think we can safely use qutebrowser.qt.* but those definitely need to be done before flipping the switch eh, not really actually, they run in an external process! Still would be nice to have them migrated though.

For the former, I'll need to experiment some more, because those scripts are sometimes useful outside of qutebrowser too. But I suppose having a qutebrowser installed would still be a safe assumption.

Should hopefully have time to get to this before this can be merged anyways.

[The-Compiler]

Hmm, I was thinking there might be something in the autoselect logic to only auto-switch to Qt6 on 6.5.2+, do you think there is any need for that?

I thought about it, but I'm somewhat lukewarm about it. I'm really not sure what happens exactly when you mix Qt 5 and Qt 6 in the same process. It might be fine when not creating a QApplication, but it still seems to me like something that could cause weird trouble.

But when doing this, we'd be forced to import Qt 6, then find out it's actually not good, and then import Qt 5 instead.

Since I have a workaround for #7732 now (which was probably the most important issue, all the rest is annoying but not a crash), I decided to not bother with it. I'm assuming once 6.5.2 is out, people are not usually going to use 6.5.0/.1 anyways.

If I need to revert that workaround (#7753 possibly...), that might be worth another thought.

[toofar]

Welp, I just noticed some of scripts/ and all of misc/userscripts are still both Qt 5.

I don't have the whole situation in my head atm but when I was looking at #7128 I had the thought that just upgrading them to Qt6 and not worrying about Qt5 compatibility would be fine. I guess the downside of that would be any distros that package the new release and don't have Qt6 available. I'm not sure how common that scenario is and how much effort we should put into polishing all the rough edges for it.