Helper for porting from deprecated KMessageBox Yes/No API

[Friedrich W. H. Kossebau]

Hi,

while as "culprit" for those API changes (HIG-matching rename of *YesNo* 
methods) I have seen to do the needed porting in some repos, there are more 
which need someone else to do that sadly.

Especially for those projects with many calls perhaps the approach we now 
developed for KDevelop might be interesting. It makes use of KMessageBox being 
a namespace, so can be amended to some degree: a shim/polyfill/wrapper header 
file named KMessageBox_KDevCompat was added, which adds the new API (as used 
in KDevelop) also with older KF versions, so one can use the new API without 
any if-version-else when including that helper header.

So with the file being added in a place part of all include dirs of that 
project, one would just include it additionally and then use the future-proof 
API. 
--- 8< ---
#include <KMessageBox>
#include <KMessageBox_OurCompat> // named to be auto-sorted next to

[...]
    // no #if KWIDGETSADDONS_VERSION vs. QT_VERSION_CHECK(5, 100, 0) here
    // where warningTwoActionsCancel was only added officially for 5.100
    int reply = KMessageBox::warningTwoActionsCancel(...);
--- 8< ---

And once the min dep of your project is KF 5.100, one only has to remove those 
includes and the wrapper/shim/polyfill file. Makes also for a nice diff 
history.

See
https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/397/
diffs#283d3562f91edb869b3331132ebb8a22bdf6ffcb

(be aware, only has those methods KDevelop uses, your project might need 
others, but that should be straightforward, being a 1:1 API change)

Cheers
Friedrich