Extract NativeDisplayDelegate and move display event handling to NativeDisplayDelegate

Display configuration events are platform specific, thus move display event processing to NativeDisplayDelegate. OutputConfigurator will then register itself as an observer of NativeDisplayDelegate which will notify observers when display configuration changes occur.

The NativeDisplayDelegate interface has also been modified to take in OutputSnapshot objects as a first step to abstracting display state. In a future CL NativeDisplayDelegate and OutputSnapshot will be updated such that X11 specific state will not be present in the interface.

BUG=333413

Review URL: https://codereview.chromium.org/173713003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253631 0039d316-1c4b-4281-b951-d872f2087c98
Fixes DesktopScreenX11::GetWindowAtScreenPoint() so that NULL is returned if a chrome browser window is occluded by a non Chrome app at the passed in point

BUG=339587
TEST=Manual, see bug
TBR=erg

Review URL: https://codereview.chromium.org/179163006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253632 0039d316-1c4b-4281-b951-d872f2087c98
Mojo: Add a "secondary buffer" to MessageInTransit.

I think I really want to move away from "unowned buffer"
MessageInTransits, but I'll do that refactor after this change (since
it'd conflict badly with this change). Also, the format of the secondary
buffer isn't finalized yet.

R=yzshen@chromium.org

Review URL: https://codereview.chromium.org/177123011

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253633 0039d316-1c4b-4281-b951-d872f2087c98
CoreAnimation startup time optimizations

Do not create any non-squashed layers before a renderer has received
a frame. The cost of BrowserWindowCocoa::Show increases substantially
if there are any CALayers in the view hierarchy. We don't gain anything
from any of the layers being added, except on 10.9, where we can squash
them, so don't create the layers unless in that situation.

Update the cr_setWantsLayer to reflect the fact that the withSquashing
argument is only specified when a layer wants either a layer with
squashing or no layer at all.

Do not create a layer for RenderWidgetHostViewMac until a frame comes
in. Also, re-arrange the layers so that RenderWidgetHostViewMac always
has at most one layer (instead of having the software layer hanging out
behind the compositing layer). This way, at startup, we use the regular
NSView drawRect methods to draw the white contents area until the
first rendered frame comes in.

Prior to this change, we'd create the software CALayer, have it clear
itself to white (and that would get uploaded to the GPU behind the
scenes), then cover up the software CALayer with the composited
CALayer once the first frame came in (because the first frame is
always going to be composited, unless you're like-in-a-GPU-less
machine).

With all of these changes in place the startup metric of
Startup.BrowserWindowDisplay is about the same with and
without CoreAnimation (in theory it should be identical, but there's
lots of noise in the measurement). Mileage may vary for metrics
after that point.

BUG=245900

Review URL: https://codereview.chromium.org/180003005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253634 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 253634