grabHelper: Rewrite documentation for GrabHelper.grab()

The previous docs were badly maintained. This does not mention
grabFocus grabs, as they'll be removed shortly.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
messageTray: Don't use focus grabs

We can easily implement much of the same behavior ourselves by
keeping track of Clutter's focus events. Reintroduce heavily
modified FocusGrabber to do the work for us.

This will temporarily break when the user selects a window until
we can make gnome-shell automatically set the stage focus.

This also removes our only use of focus grabs, so remove those
as well.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
grabHelper: Remove explicitly having to select modal

https://bugzilla.gnome.org/show_bug.cgi?id=700735
Rework window / actor focus handling

The duality of the Clutter's key focus and mutter's window focus has long been
a problem for us in lots of case, and caused us to create large and complicated
hacks to get around the issue, including GrabHelper's focus grab model.

Instead of doing this, tie basic focus management into the core of gnome-shell,
instead of requiring complex "application-level" management to get it done
right.

Do this by making sure that only one of an actor or window can be focused at
the same time, and apply the appropriate logic to drop one or the other,
reactively.

Modals are considered a special case, as we grab all keyboard events, but at
the X level, the client window still has focus. Make sure to not do any input
synchronization when we have a modal.

At the same time, remove the FOCUSED input mode, as it's no longer necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
global: Clean up the code that actually sets the shape on the stage

Instead of having "dummy" setters that do work, split out the parts
that do work into their own function.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
global: Automatically unshape the stage X window when we take a modal

This prevents the "client" from having to do it, and removes one part
of the FULLSCREEN input mode.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
layout: Don't use the input mode to block events to windows

Instead, use the standard Clutter scene graph and our Chrome system.

This also removes our last use of the input mode, so remove that as
well.

https://bugzilla.gnome.org/show_bug.cgi?id=700735
st: optimize box-shadow rendering

Currently the box-shadow is rendering is done like this :

The first time we want to render a node that requires a box-shadow, St
creates an cogl offscreen surface of the size of the allocation and
renders the box into this offscreen buffer using modulation on the
alpha channel, this buffer is then blurred according to the CSS
parameters.

The problem with this method is that every time an StWidget is
resized, its box-shadow offscreen buffer has to be resized and
therefore rendered and blurred.

This patches propose an optimization for this use case by rendering
the box-shadow only once but at a size that is independent of the
StWidget's size. Then every time we need to paint this box-shadow, we
just render this offscreen buffer using a 9-slices.

This method only works when the allocation of the widget is bigger
than the minimum shadow size on which we can apply a 9-slices, that is
given my the radius of the corners. If the allocation is smaller than
this minimum size, we then fallback to the fully render/blur the
shadow (like before this patch).

https://bugzilla.gnome.org/show_bug.cgi?id=689858
tests: add animated box-shadow test to demo optimized painting
st-theme-node: refactor calls to render css box
st-theme-node: reuse box-shadow materials between paint states when possible
st-theme-node: init cached state properly
loginDialog: don't call nonexistent setInitialKeyFocus function

commit ea02380c1524c28e6538ffedb789a12c298742ab changed the login
dialog to not use ModalDialog anymore.  There's still one lingering
setInitialKeyFocus method call in the source, which will cause an
exception to be thrown when users have their user list disabled.

This commit fixes that.

https://bugzilla.gnome.org/show_bug.cgi?id=703874
modalDialog: Minor coding style fix

https://bugzilla.gnome.org/show_bug.cgi?id=703807
style: Fix focused app view controls

Moving from fixed width to horizontal padding for the app view control
buttons broke the focus style, in that buttons may change size on
keyboard focus changes. Fix this by using the correct horizontal padding
when focused.

https://bugzilla.gnome.org/show_bug.cgi?id=703807
style: Fix extension list style in looking glass

No idea how this got unnoticed since forever, but code and stylesheet
didn't quite agree on the same name ...

https://bugzilla.gnome.org/show_bug.cgi?id=703807
calendar: Fix line-wrapping of calendar events

Commit 929636ebd0b8f428 broke line-wrapping of longish calendar events,
add back the required CSS width.

https://bugzilla.gnome.org/show_bug.cgi?id=703893
lookingGlass: Use uiGroup as parent instead of panelBox

Currently lookingGlass relies on some odd BoxLayout behavior, which
allows children to use fixed positioning without affecting the parent's
size request. As this behavior is scheduled for removal, add the
looking glass dialog directly to Main.uiGroup.

https://bugzilla.gnome.org/show_bug.cgi?id=703808
overview: Add coverPane to stack instead of BoxLayout

The event catcher that covers the entire primary monitor during
transitions is currently inside a BoxLayout, relying in its
odd support for fixed position actors.
We already have a proper stack widget in place, move it there.

https://bugzilla.gnome.org/show_bug.cgi?id=703808
st: Remove support for fixed positioning in BoxLayout

It is the job of layout containers to arrange their children; having
a hidden feature that *also* allows children to be positioned freely
outside the parent's allocation is just odd.
With the last user of the feature gone, kill it.

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