telepathyClient: decline dispatch op when approving unsupported channel type

It shouldn't happen in theory but best to be safe than sorry.

https://bugzilla.gnome.org/show_bug.cgi?id=677457
telepathyClient: ignore invalidated channels

There is a race if a channel is invalidated during its preparation: the
'invalidated' signal is already emitted so the Shell will never notice.
We fix this by simply checking if the channel is already invalidated when
receiving it from telepathy-glib.

In the approving case, we reject the full ChannelDispatchOperation as we only
support approving one channel at the time.

https://bugzilla.gnome.org/show_bug.cgi?id=677457
Depend on gjs 1.33.2

Shell uses the 'format' module which has been introduced in gjs 1.33.2.

https://bugzilla.gnome.org/show_bug.cgi?id=678396
shell-app: Update app menu if necessary

Currently we assume that GTK_UNIQUE_BUS_NAME is shared between all
windows of an application. This assumption does not hold true for
applications that specify G_APPLICATION_NON_UNIQUE, so make sure
to update the menu as necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=676238
Enable the Screen Reader menu item

https://bugzilla.gnome.org/show_bug.cgi?id=663256
workspace: Remove unused method

This one hasn't been used for quite a while now ...

https://bugzilla.gnome.org/show_bug.cgi?id=678416
workspace: Minor cleanup

_hideAllOverlays() has only been used in a single place for quite
some time now, so move its code into the caller and save a loop.

https://bugzilla.gnome.org/show_bug.cgi?id=678416
Disable unredirection when a modal operation is active

When the shell takes control of the screen (for example to show
a modal dialog or to lock the screen), it must reestablish itself
on top of the stack, and in particular restore any unredirected
window so that it is composited below the Shell UI.

Reviewed-By: drago01 in IRC.
build: Make folks optional

The dependency chain spirals out from folks->zeitgeist->xapian...and
I'm really not interested in pulling in all of that into the core
shell.

There is work on splitting out contact search into gnome-contacts; I'd
add a bug link but Bugzilla is down.
build: Fix the case of building without folks
mount-operation: fix exceptions when showing password entry

This is a fallout from some changes in MessageTray.Source, which now
requires either defining the iconName/iconType properties on it, or
implementing createNotificationIcon, and we're not doing any of those.
Fix it by storing the gicon of the source object and using a helper
method to create the icon actor on demand, to avoid any case when the
same actor might be added twice to different containers.

https://bugzilla.gnome.org/show_bug.cgi?id=678428
mount-operation: close the password entry on operation abort

If the device disappears in the middle of a mount operation, make sure
to dismiss the password prompt automatically.

https://bugzilla.gnome.org/show_bug.cgi?id=673787
autorun: change logic for ignoring volumes

Previously, a volume was being ignored from autorun if one of these two
conditions were met:
- its mount root file had a native scheme and was mounted in a
  non-hidden location
- it had a volume that could have been automounted, and had a flag set
  by the shell to allow autorun

In order to effectively ignore volumes that we don't mount ourselves
from our notification system, we have to meet both conditions at the
same time instead.

https://bugzilla.gnome.org/show_bug.cgi?id=660595
autorun: simplify code

Split autorun conditions into separate logic blocks instead of a single
huge if.

https://bugzilla.gnome.org/show_bug.cgi?id=660595
autorun: only obey allowAutorun flag for transient notifications

Only apply the allowAutorun flag for transient notifications, not for
mounts that end up in the resident notification well.

Also, stop looking at volume.can_automount() here, since we already
checked that previously in the mounter, and allowAutorun is enough.

https://bugzilla.gnome.org/show_bug.cgi?id=660595
automount: don't allow autorun for things we mount at startup

We don't want to potentially flood the user with notifications about
mounts when starting up the system.

https://bugzilla.gnome.org/show_bug.cgi?id=660595
NetworkMenu: sort wifi networks by strength

Sorting by strength is what the other OSes do by default, and it
provides a better UX (by offering your hotspot and router before
the one from your neighbor).

https://bugzilla.gnome.org/show_bug.cgi?id=658946
NetworkMenu: prefer wifi/3g over vpn in the panel

Wifi and mobile broadband have signal indicators and are thus
more useful than vpn icons in the panel. Therefore, in the case
we have both wifi/3g and VPN we prefer the former as the "primary
icon" and add a lock next to it.
Behavior when VPN is added to wired or other connections is still
preserved: the wired icon is replaced by vpn.

https://bugzilla.gnome.org/show_bug.cgi?id=672591
mount-operation: turn the passphrase prompt into a dialog

Instead of a notification. This also adds space for a checkbox allowing
to remember the passphrase.

https://bugzilla.gnome.org/show_bug.cgi?id=674962
automount: re-use the same dialog when passphrase doesn't match

Wait until the completion of the mount operation before dismissing the
passphrase dialog, so in case it fails, we can re-use the same dialog
with an error message (like e.g. PolicyKit auth dialogs) instead of
showing a brand new one.

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