Stable API for Runcontrol / Runworker

RunControl, together with a number of dynamically created instances of RunWorker (45 different subclasses), is responsible for running user applications / profilers / debuggers, etc. The current implementation is error-prone with regards to the manual managing of the RunWorkers' lifetime, hidden dependencies between them, unexpected state transitions, and cumbersome data exchange between them.

The alternative design would be to use TaskTree as a replacement of RunControl, and operate on task tree recipes returned by relevant RunWorkerFactories instead on instances of RunWorker subclasses.

More details:

The request for "stable Qt Creator Plugin API" comes up regularly. We currently still need the freedom to change also core API, but for limited areas this seems in reach. This here is one of them.

The current API is sufficient for the current purposes and has not changed significantly since 2019, but it's not good enough to set in stone in its current shape.

We have (among others) two special kind of plugins, one set providing "platform" support (i.e. organize the actual of process on certain devices, possibly accessing the file system there - 'local', android, baremetal, ios, (remote)linux, docker, qnx, [webassembly, vxworks]) and "tool" support (input/output handling of certain 'tools' that can potentially run on different devices = 'normal application run', debugger (c++/qml/mixed - gdb/lldb/cdb), qmlprofiler, perf, profiler (memcheck, cachegrind),). The challenge here is to organize combination of those (i.e. "run a given tool on a certain plugin") without creating dependencies between the respective "platform plugin" and "tool plugins" (internally known as "The Matrix Problem" as the "obvious" solution to have specialized plugins for each combination does not scale).

With the current RunWorker system we have a partial solution to the Matrix problem, splitting the platform and tool parts into two workers, but setting up the right dependencies between them, especially when extra glue is needed (e.g. using PortGatherers to get free ports for comunication) it is pretty much ad hoc.

We should move the whole machinery to use uniformly TaskTree for dependency management and Aspects for data.