selection-toolbar: Fix button positions

GtkActionBar (and current GtkHeaderBar) has different pack_end
semantics than GtkHeaderBar in GTK+ 3.10.x.
tracker-controller, query-builder: Simplify the use of PhotosQueryFlags

... by passing the relevant PhotosOffsetController from the
PhotosTrackerController itself, instead of figuring it out based on
PhotosQueryFlags inside the query builder.

Fixes: https://bugzilla.gnome.org/709367
base-manager: Be careful about objects with blank filters

When generating a filter for "all", an object with a blank filter, ie.
"(true)", should be skipped. Otherwise it will lead to
"(true) || cond1 || cond2 ...", rendering the whole filter useless.

Fixes: https://bugzilla.gnome.org/709367
Detect creation of collections and show albums within albums

Our use of PhotosQueryFlags was becoming too convoluted. We were using
PHOTOS_QUERY_FLAGS_NONE for quite a few subtly different cases:
 - Queries where we only want nmm:Photo items
 - Queries where we want any item that is a nmm:Photo or a collection

Let us not do that. We will now use PHOTOS_QUERY_FLAGS_OVERVIEW for the
former and PHOTOS_QUERY_FLAGS_NONE for the later.

It turns out that we do need a builtin "all" PhotosSearchType, even
though we will always have the distinction between collections, photos
and favorites in the main application modes. We need it to represent
PHOTOS_QUERY_FLAGS_NONE queries where we want any item that is a
nmm:Photo or a collection:
 - To find out the contents of a collection, which can have nmm:Photo
   items or other collections inside it
 - To catch newly created Tracker objects that could be a nmm:Photo or
   a collection

However, this does clean up how the builtin "all" PhotosSearchType was
handled.

Fallout from 3d4f17a87a4da426c861057e989602387ece83fb

Fixes: https://bugzilla.gnome.org/709367