Fix design flaw which might cause slots to be invoked on partially destroyed objects

With widgets, if a child widget object would emit in its destructor, it can lead to situation where connected slots might be invoked while objects are in destruction and can be only partially destroyed in the when connection triggers when the parent is in destruction. While we do disconnect when the receiver is destroyed, the problem ultimately is that it hasn't finished destruction yet.

With signals and slots, this forces the developer to consider the following workarounds:

(A) a child object must not send signals from its destructor and
(B) it must not call any function that could send a signal or
(C) disconnect in the destructor all signals of this class type.
(D) Or parent must manually delete the child object which could emit in its destructor.

To summarize:
the above changes should be done to all classes. As this is almost impossible, one can basically safely use signal-slot connection only if:
(1) a sender isn't direct or indirect child of the receiver or
(2) sender won't emit signals in its destructor and won't call any function that emits.
The former might be hard to implement in some cases because an object could be moved to a different parent and that new parent could be a receiver.
The latter on the other hand can be troublesome especially if the source code isn't available.

Depending on the project adding `disconnect()` statements manually in the destructor causes a lot of extra work, and is not developer-friendly and is error prone. C++ unfortunately doesn't provide any pre-destructors, which would theoretically speaking fix the issue if such existed.

While this design has been around over a decade now and cannot be considered as a bug, it can be argued that it is a design flaw and affects re-usability of the code negatively. So, the suggestion is to consider improving the current design in a way that would allow an easy and safe use of those widgets which might emit in their destructor.

Please see the related bug reports at:
https://bugreports.qt.io/browse/QTBUG-105473 (has a minimal example which naturally does not cover all the use cases)
https://bugreports.qt.io/browse/QTBUG-33908