manual tests should be buildable standalone

On Teams it was suggested to use -DQT_BUILD_MANUAL_TESTS. That means building all Qt manual tests, which will increase build time. Besides, we have name conflicts: there is a manual test and an autotest both called qtabbar, more than one executable called "dialogs", the gifs manual test in controls2 was not buildable at all, etc. So it's currently not possible AFAICT.

The other suggestion is to use qt-cmake-standalone-test, which seems ungainly.

In Qt 5, it was convenient when somebody reports a bug that's hard to reproduce, to find a manual test that covers the functionality and ask them to build that and try it. It was as simple as going into the installed source directory, qmake and make. I don't know what I'd tell them now if that comes up. Apparently we even ship qt-cmake-standalone-test, but... why?!?

The individual CMakeLists.txt do not have project(executable), nor minimum required version (two first things cmake complains about), but instead have internal magic like

# special case begin
if(NOT TARGET Qt::Svg OR NOT TARGET Qt::Quick OR NOT TARGET Qt::Qml)
    return()
endif()
# special case end

qt_internal_add_manual_test ...

This isn't sustainable. We need a comprehensible build system. I'm not interested in cluttering my mind with cmake idiosyncracies that are not portable and obviously have their future in the trash bin anyway. Therefore for me, manual tests that I wrote myself are not accessible, because the .pro files are gone. There's not even a good reason for that, is there?

If cmake can't be fixed, we should restore the .pro files. Probably we should anyway, for the sanity of the users. When I want to build one, I have to revert the patch that removed the .pro

Maybe we should write complete standalone CMakeLists.txt for all these, but then I suppose that causes problems to automate the testing? But it's hard to believe nobody else has that problem, building multiple executables in subprojects. There must be a more standard solution.