main: don't hook up overview keybinding until after startup

Toggling the overview during the startup animation reportedly
causes stuck grab and other odd behavior.

There's no reason to handle toggling the overview during this
time anyway.

This commit defers that handling until after startup.

https://bugzilla.gnome.org/show_bug.cgi?id=694837
theme: use standard styling for ibus candidate popups

This is more consistent and helps with legibility.

https://bugzilla.gnome.org/show_bug.cgi?id=694796
status/keyboard: Don't allow the switcher in the message tray

SwitcherPopup relies on being able to pushModal(), setting the stage
input mode to FULLSCREEN, and then doing regular event processing on
the actor it adds to uiGroup. But MessageTray uses GrabHelper which
sets up a 'captured-event' handler on the stage and thus gets all
events itself.

This, of course, breaks the switcher if it's brought up in the message
tray so, for now, we'll just prevent it from being used there.

https://bugzilla.gnome.org/show_bug.cgi?id=693907
Migrate from libgnome-keyring to libsecret

 * See: https://live.gnome.org/GnomeGoals/LibsecretMigration

https://bugzilla.gnome.org/show_bug.cgi?id=679851
Calendar: force all months at the same height

Add one or two weeks from nearby months to avoid changing the menu height
when navigating it.

https://bugzilla.gnome.org/show_bug.cgi?id=641383
Calendar: freeze updates when the event source is loading

Check if the event source is currently doing an async call, and prevent
UI updates in that case. This avoids a flash of "No updates" when switching
months.

https://bugzilla.gnome.org/show_bug.cgi?id=641383
Calendar: clean up code by always having an event source

Instead of sometimes having an event source and sometimes not, use
the empty event source when the session mode says the calendar is
disabled. This way, the code can assume an event source object and
avoid checks.

https://bugzilla.gnome.org/show_bug.cgi?id=641383
Calendar: dim days from other months, even if they have events

Invert the order of the declarations, so those for calendar-other-month-day
take priority over those for calendar-day-with-events.

https://bugzilla.gnome.org/show_bug.cgi?id=641383
Calendar: only show events when configured in Evolution

When no calendars are enabled, hide the events pane completely instead
of showing it empty.

https://bugzilla.gnome.org/show_bug.cgi?id=680083
Updated Lithuanian translation
layout: Prevent going into negatives with the pressure

We capped each event to 15px of travel, but we didn't do the same
cap when subtracting events that were too old.
layout: Debounce triggering barriers

Ensure that the pointer leaves the barrier before we trigger again.

For the message tray case, this doesn't matter much, as the trigger
won't have any effect after the grab is taken, but in the overview
HotCorner case, this ensures that we don't trigger the overview
transition many times simply by holding pressure against the hot
corner, which is easy to do accidentally.
layout: Move the keybinding mode to the user of PressureBarrier

For the hot corner case, we want to have the pressure apply both in
and outside of the overview, so we need to move this to the user. At
the same time, use keybinding mode math that's more like what's used
in filterKeybinding.

While it may seem like an abuse of the KeyBindingMode API, it may
become more reasonable if one thinks of the pressure barrier as a
binding of sorts, just applied to the mouse. If a ButtonBinding API
was added to mutter, I think we'd use the existing KeyBindingMode
infastructure there as well.
layout: Move tray-specific event filtration to the user of PressureBarrier

For the HotCorner, we want to have different logic for tossing out
specific events based on the grabbed state, etc. so make us have
to pass in an event filter callback.
layout: Allow multiple barriers to contribute to a PressureBarrier

For the HotCorner case, we want to have to barriers both contribute
to the hot corner pressure, so we can't simply wrap the pressure
barrier.
layout: Construct the primary monitors's hot corner, too

This cleans up the code considerably, and makes it so that
one path creates all hot corners for all monitors. Why this
wasn't done originally, I have no clue...

The one complication is debouncing if the button and hot corner
are triggered in rapid succession, so we just move this tracking
to the overview.

https://bugzilla.gnome.org/show_bug.cgi?id=663661
layout: Pass the X/Y coordinates when constructing the corner

There's no guarantee that hot corners will have an actor in
the future -- they may be powered entirely by a barrier.

https://bugzilla.gnome.org/show_bug.cgi?id=663661
overviewControls: only show chat icon in messages indicator for chats

Only show the chat icon in the new messages indicator when at least one
among the outstanding notifications is a chat.
main: don't explicitly hide the stage

It's hidden by default, so there's no point in hiding it explicitly.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
main: defer session update until startup animation

We currently call the session updated handler as soon as
the session modes are read.  This handler sets up keybindings
for leaving the overview (if a user session) and shows the
login dialog (if a gdm session).

We can't do the latter until the stage is mapped because it
takes a grab, and we don't need to do the former until the
user goes into the overview.

This commit defers processing session updates until the
the layout manager says start up is prepared.

It fixes a race condition at login screen startup now that
we don't show the stage right away.

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