BackgroundThread API can have issues

[fuzyll]

From #6300:

This is a mess of a race condition in the BackgroundThread api. What is happening is that the BackgroundThread doesn't actually hold a strong reference to its QObject parent and thus the view is getting destroyed while the thread is running. The thread only checks that its parent exists between each task, and doesn't actually stop its parent from being deleted mid-task. I'm looking into a way to have QObject::destroyed wait for the current task to finish before actually destroying the object, though this is quite janky.

There's been some additional discussion about this at the office wrt futures and whatnot. I don't remember all the details, but I'm making this issue so we don't lose track of the fact that this is still a problem in some contexts.

[CouleeApps]

So I can think of two methods to solve this:

1. Keep state around in a form that can outlive the UIs that get destroyed. Something like a std::shared_ptr with a view's state could work, or QSharedDataPointer maybe if anyone here knows how to use that.
2. Wait for the background task to finish when closing the UI, with something like a QObject::destroyed signal handler that waits for the task to finish.

Option 1 is a rather large lift, since there are a bunch of places using BackgroundThread that need to be audited and potentially modified to save their state better.
Option 2 is a smaller code lift but has a downside of freezing the UI until the task completes, since you have to wait on the main thread. This is how we solved #6300 here:

binaryninja-api/view/sharedcache/ui/symboltable.cpp

Line 156 in 34e464b

watcher->waitForFinished();