Use coroutines to run dialogs asynchronously

[andy128k]

I'll be honest. I have no idea if this works properly. Few AIs helped me to craft this code. Generally, I'd like to have something like async/await in Rust, so I gave it a try.

[mvo5]

I have not looked in detail but I would be very hesitant here, its an interesting idea and probably fun to play with - but staying as close as possible to gtk is preferable IMHO. I have a hard time maintaining this as is so anything that adds burden feels not ideal. Sorry if that sounds disappointing.

[andy128k]

@mvo5 I totally understand your point. The piece of code in this PR is awful (in a part where coroutines are defined). I don't mind if this PR will be rejected. I'd just want to clarify the future direction, so, I could contribute to the project.

---

The problem with sticking to Gtk is that Gtk4 does not have synchronous dialog API anymore. See https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-blocking-dialog-functions

So, all the places which use dialogs and gtk_dialog_run (not even saying about gtk_events_pending) needs to be fully reworked. That'd be a major rewrite of the whole application.

It'll be not possible to have functions like bool RGUserDialog::showError() anymore. Any time a function needs to show a dialog (e.g. get user's consent) it needs to be split into two functions and pass an intermediate state (stack variables) somehow from one to another.

The point of using coroutines is that application's code may still look the same (or resemble the original code) but be asynchronous. In this PR co_await co_run_dialog() is where gtk_dialog_run used to be.

I've mentioned Rust above, so, Gtk-rs solves this by wrapping signals and running futures (coroutines) on top of Glib event loop. See gtk::Dialog::run_future.

I successfully used Rust async functions in a few rewrites from C++/Gtk3 to Rust/Gtk4. So, I gave C++ coroutines a try to replicate the pattern.