[GTK] Fix Combo copy/paste tests on Gtk 4.x

[akurtakov]

Gtk 4 no longer provides API for doing that but rather a built-in action to activate. This requires to spin the event loop to process it.

[github-actions]

Test Results

   485 files   -    61     485 suites   - 61   19m 42s ⏱️ - 13m 28s
 4 335 tests  -    91   4 322 ✅  -    87   12 💤  -  5  1 ❌ +1 
13 075 runs   - 3 675  12 958 ✅  - 3 665  116 💤  - 11  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 035a973. ± Comparison against base commit cde95ee.

This pull request removes 91 tests.

AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_dollarSign
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_emptyString
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letterA
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16LE_null
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_AsciiLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_Asciiletter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_LotsOfLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letters
…

♻️ This comment has been updated with latest results.

[HeikoKlare]

Since the change only affects GTK4, it is fine to go in RC2. You have my approval for that.

Regarding the change itself: if there is no way around this, it's probably fine. But still it seems a bit dangerous to me as this will spin the event loop at some rather unexpected place. As far as I understand, the paste() method on a combo can be called from anywhere in the UI thread, such that this will start spinning the event loop at an arbitrary place. We attempted to do something similar in Edge browser and concluded that it's not a good idea (and also implemented some alternative): #1773
On Windows it's possible to peek specific messages from the OS to not process everything but only the kind of event you are waiting for. But I don't think that's possible on GTK, so probably there is no way around spinning the whole event loop.

[laeubi]

I agree with @HeikoKlare that spinning the event queue is not really nice and wondering why it is required at all should this not happen anyways (sooner or later) and is the problem probably more that one expect the past happen instantly?

Should we probably just enhance the javadoc that the paste can happen asynchronously and any code that relies on the happen-before should use a display.asyncExec call before access the widget state after that?

[iloveeclipse]

I assume this can be closed now, superceeded by #2489

[akurtakov]

This is considered too risky so a documentation is being added and tests event loop spinned instead.