Whenever the selection or window modes changed, if the app.search
GAction's state was FALSE, the Searchbar used to be removed from the
MainToolbar. It would be added back if the new mode supported search.
The photos_searchbar_handle_event method used the presence of a parent
container to decide whether it's supposed to handle keyboard events
for a given mode.

This hinges on the app.search GAction having the right state before the
MainToolbar handles the mode change. However, that's not the case when
going from SEARCH (without an active collection) to PREVIEW. The
GAction is toggled in photos_embed_prepare_for_preview when the search
state is saved. That's after the application has entered PREVIEW.
Therefore, pressing a key when previewing a search result will show the
Searchbar, which it is not supposed to.

The second problem arises if the Searchbar is removed and added while
it was animating away. It shows a grey bar, without any entry, once it
is added back to the MainToolbar. Supposedly the remove/add cycle in
the middle of the animation confuses GTK+.

This isn't observed in practice because commit 77036628
prevents the Searchbar from being hidden during mode changes. It's
only hidden when viewing a collection, which doesn't use the same code
path as selection or window mode changes. However, that's going to be
a problem once the faulty behaviour introduced by commit
77036628 is fixed in a subsequent patch.

All that can be addressed, and the code simplified, if the Searchbar is
never removed from MainToolbar. Instead of relying on the presence of a
parent, it can use the GAction's enabled property to decide whether to
handle keyboard events or not.

As a result, this reverts commit fa26cf48 and keeps the code in
sync with gnome-documents.

https://bugzilla.gnome.org/show_bug.cgi?id=786936