Run resource previewer on the main thread if using GL compatibility

[RandomShaper]

I don't know why the issue was surfaced by #86587, but to my understanding, it was already there previously. The issue is that with OpenGL (Compatibility rendering method) you can't deal with textures from arbitrary threads. The rendering server tries to do the right thing by sending the tasks to a queue, but the resource importer will blindly continue doing its job without waiting for them to be created. The worst consequence is that, given the relevant texture-related functions take references to resource references (Ref<>&), by the time the previewer thinks it's done with some images it can decrease their refcount to zero. Because of that, there are dangling references by the time the queue is flushed later.

This PR fixes the ill situations by just letting the main thread flush any outstanding resource importing tasks every idle frame. That ensures that any previewer, either one that directly deals with rendering or one that doesn't, because in the end all of them have to create the preview images, don't incurr in sync issues.

This will affect the responsiveness of the editor while there are queued preview tasks. The code tries to let the editor breathe a bit to avoid looking frozen.

#77004 should fix the issue at some point, so this PR may be reverted or the approach re-assessed. Some care will be needed anyway in the resource previewing code so that lifespans, etc. are properly handled. Pre-4.3 there's no other fix than this.

Finally, some extra testing would be appreciated.

Fixes #87196.

[YuriSizov]

TilesEditorUtils is a very close copy of the entire EditorResourcePreview class. I assume it needs the same fix?

[RandomShaper]

TilesEditorUtils is a very close copy of the entire EditorResourcePreview class. I assume it needs the same fix?

Good question. I've checked the code and it seems it's fine already. The code there is already safe by using several sync mechanisms to let the main thread deal with the viewports and eventually, only when it's known the texture is ready, claiming the results.

By the way, EditorResourcePreview may want to do something similar, which would still allow some work to happen in parallel on another thread, but such an approach would involve adding the needed "sync points" across both that class and all the preview plugins. I don't think it's very worth the work, when an upcoming PR will fix the underlying issue for good, unless the approach in this PR turned out to be too impractical in practice (he-he, what an expression).

[akien-mga]

Looks good to me.

[akien-mga]

Tested and confirmed this fixes #87196.

[akien-mga]

Thanks!