Remove Views dependency from window_animations.cc

Remove Views dependency from window_animations.cc

. Adds an "owner" property to Layer that identifies its LayerOwner. If a Layer is not owned by a LayerOwner that's OK - this property will be NULL.
. Provides a more formal API to LayerOwner, e.g. SetLayer, which initializes the bound Layer's owner property.
. Updates Window and View to use this new API.

R=sky@chromium.org
BUG=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255106

[Ben Goodger (Google), 2014-03-05 06:22:59]

This is a different approach than we discussed. The trick was as you noted there
were many LayerDelegate implementations, and in several cases there was not a
1:1 mapping between layer and layer-delegate, and it wasn't often the case that
the objecting implementing LayerDelegate could easily get at the LayerOwner to
acquire the layer.

So instead I made a more formal API to LayerOwner and made Window/View use it,
and in implementing it in LayerOwner stow a pointer to the owner on the layer,
so the code in window_animations.cc can get at it.

In studying this I think I've identified a potential bug. The various layers
whose delegates are NOT Window/View are not handled by window closing
animations. What does this mean in practice? When you slow down animations you
see that when you close a window, the shadow disappears immediately and the
window content fades out smoothly. This is because the shadow layer is destroyed
immediately rather than becoming owned by the animation. If ImageGrid, etc. were
converted to use LayerOwner after this CL, I predict this bug would disappear.

[sky, 2014-03-05 15:38:59]

LGTM

Nice!

[Ben Goodger (Google), 2014-03-05 16:12:58]

The CQ bit was checked by ben@chromium.org

[commit-bot: I haz the power, 2014-03-05 16:13:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ben@chromium.org/184983005/40001

[commit-bot: I haz the power, 2014-03-05 18:51:13]

Change committed as 255106