GrepOutputView creates a hidden GrepDialog on start to restore search
settings from history. GrepOutputView also creates a hidden GrepDialog
when its Refresh action is triggered. In both cases the GrepOutputView
becomes GrepDialog's parent, and thus will be valid when the dialog is
ready to display results. Also in both cases the search results should
not be displayed in a GrepOutputView from another area if that area
becomes active before GrepDialog::startSearch() is invoked. And there is
no need to raise the GrepOutputView in these cases either.

GrepViewPlugin creates and usually shows GrepDialog for various reasons.
The dialog is modeless, so the user can activate another area before
starting a search in it. The results should be displayed in a
GrepOutputView within the area active at the time of a search start.
Therefore the old IUiController::findToolView()-based implementation
remains for this case.

Restoring search history in a session that contains zero projects (all
closed), could cause a crash in a nested event loop inside
UiController::loadAllAreas(), because UiController::findToolView()
returns nullptr then and GrepDialog::startSearch() does not check the
returned pointer. OktetaDocument can create such a nested event loop if
a binary file is open in the session.

BUG: 456767
FIXED-IN: 5.10.221200