[Development] new "debugsupport" module and API

[Ulf Hermann]

>> Is anyone opposed to keeping this in a separate qtdebugsupport.git
>> repository, then?
>
> With what compatibility promises regarding code and protocol?

I would promise source and binary compatibility and backwards as well as 
forward compatibility of the protocol. At the same time I would publicly 
state that we'll consider replacing the whole affair with TCF or 
something similar in Qt6 and deprecating the the debugsupport module then.

We in fact already have to maintain protocol compatibility so that older 
and newer tools can debug different versions of Qt. We can as well make 
that explicit: The protocol format is not going to change in Qt5 
anymore. In order for qtdeclarative to depend on qtdebugsupport we need 
it as an essential module which has to provide source and binary 
compatibility. (Alternately we could restart the discussion about 
submodules, but I'll only do that as last resort ...)

At the same time I know that this suffers from a serious case of NIH and 
I would like to drop it at some point. However, we should really not 
further complicate it. Retrofitting TCF into the current architecture 
would be a major mess. With my refactoring I tried to keep the changes 
to existing plugins minimal while reducing code duplication. That of 
course retains bad architectural decisions of the past which are 
incompatible with any state of the art debugging framework. The most 
important incompatibility revolves around the need for proper 
asynchronous messaging: The protocol should track messages from client 
and server and associate them with each other as "commands" and 
"results", so that you can send multiple commands in a row without 
waiting for replies in between. The V4 debug service does that on its 
own, but it should really be done by the server for all services. A good 
architecture that supports this kind of interaction looks different than 
one that doesn't. In addition to that a good architecture that does that 
on a client which sends commands and receives results (and possibly 
asynchronous events) looks different than an architecture for a mostly 
reactive server. That means, once we do it properly, there won't be much 
of a point in keeping server and client in the same library anymore.

I propose to clean it up a little now and redo it from scratch in Qt6.

regards,
Ulf