The legal ways to request a state change are now clearer and stricter
than before:
 - You cannot move to the preview directly. You must set a non-NULL
   active item to do that.
 - You cannot set a NULL active item to go back from the preview. You
   must use the go_back method for that.

We assert pre and post conditions for state transitions to enforce
these rules and catch programmer errors.

Earlier, the mode would be updated after "load-started" was emitted.
That is no longer the case. Signals are emitted only after the state
change is complete. So adjust accordingly.

Stop abusing "load-started" to do things that should be performed in
the "window-mode-changed" handler. ie. code that should not be run
while navigating within the preview.

Untangle and consolidate the search save and restore logic. Instead of
using hard to read and racy conditions in a
PhotosItemManager::active-changed handler, we have now split it into
the "window-mode-changed" and "active-collection-changed" handlers.
This is much easier to read and understand. The logic to relax the
search criteria when viewing a collection has now been moved to
PhotosEmbed from PhotosOverviewSearchbar. Otherwise, the
"active-collection-changed" handlers in these two classes would stomp
on each other.

Even though the state represented by these two classes are tightly
coupled (preview must have an active item, and you can't be in
overview with an active item, etc.), ItemManager sounds like a
misnomer for the purposes served by the ModeController. Due to my
inability to think of a better name, the ModeController type is now an
alias for ItemManager and we have retained the method names.

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