gdm: support pre-authenticated logins from oVirt

oVirt is software for managing medium-to-large scale deployments of
virtual machine guests across multiple hosts. It supports a feature
where users can authenticate with a central server and get
transparently connected to a guest system and then automatically get logged
into that guest to an associated user session.

Guests using old versions of GDM support this single-sign-on capability
by means of a greeter plugin, using the old greeter's extension
API.

This commit adds similar support to the gnome-shell based login screen.

How it works:

* The OVirtCredentialsManager singleton listens for

  'org.ovirt.vdsm.Credentials.UserAuthenticated'

  D-Bus signal on the system bus from the

  'org.ovirt.vdsm.Credentials'

  bus name. The service that provides that bus name is called
  the oVirt guest agent. It is also responsible for interacting
  with the the central server to get user credentials.

* This UserAuthenticated signal passes, as a parameter, the a token
  which needs to be passed through to the PAM service that is specifically
  set up to integrate with the oVirt authentication architecture.
  The singleton object keeps the token internally so it can be queried
  later on.

* The OVirtCredentialsManager emits a signal 'user-authenticated' on
  it's object once the dbus signal is triggered

* When the 'user-authenticated' signal is emitted, the login screen
  tells GDM to start user verification using the PAM service. The
  authentication stack of the service includes a PAM module
  provided by oVirt that securely retrieves user credentials
  from the oVirt guest agent. The PAM module then forwards those
  credentials on to other modules in the stack so, e.g.,
  the user's gnome keyring can be automatically unlocked.

* In case of the screen shield being visible, it also will react on that
  'user-authenticated' signal and lift the shield.
  In that case the login screen will check on construction time if
  the signal has already been triggered, and a token is available.
  If a token is available it will immediately trigger the functionality
  as described above.

Signed-off-by: Vinzenz Feenstra <evilissimo@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=702162
messageTray: Clean up code that determines if something is clearable

https://bugzilla.gnome.org/show_bug.cgi?id=710115
messageTray: Move the notification policy classes here

The NotificationDaemon really should be for the hookup of remote
notifications, rather than policies.

https://bugzilla.gnome.org/show_bug.cgi?id=710115
messageTray: Only connect to a notification's open/destroy once

If we pushNotification the same notification multiple times, we
won't append it to the array again, but we will attach multiple
handlers needlessly.

https://bugzilla.gnome.org/show_bug.cgi?id=710115
messageTray: Split out the notification's destroy handler

This is complex enough to split out.

https://bugzilla.gnome.org/show_bug.cgi?id=710115
messageTray: Don't remove and re-add the focus group on button changes

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