Mac: Fix performance issues with remote CoreAnimation

Mac: Fix performance issues with remote CoreAnimation

There are two separate issues here.

First, virtualized contexts did not appropriately force the switch
between GPUs when made current. The forced switch would only happen
when the real context was changed, which is much less often. This issue
is not specific to remote CoreAnimation, and also impacted the IOSurface
path (it has likely been an issue since virtual contexts were enabled).

Second, when the GPU switches, tear down and re-create the CAOpenGLLayer
that is exported across processes. This is already done for the
IOSurface path, in IOSurfaceLayerHelper. When the CGLContextObj for the
CAOpenGLLayer is re-created, it will be running on the current GPU.
Without the re-creation, it may stay indefinitely on the old GPU. It is
from this context that we read the CGL renderer ID which we will pass
to the rendering context, to force it to switch GPUs as well.

BUG=424433

TEST=
0. Get a GPU-switching Mac with no external displays and install
   gfxCardStatus
1. Ensure that you are on the integrated GPU (gfxCardStatus should say
   'i')
2. Start Chrome with the FPS counter enabled
3. Open poster circle in one window
   a. It should run at 60 fps
4. Open a WebGL demo (San Angeles) in another window
   a. This should trigger a switch to the dGPU (gfxCardStatus should say
      'd')
   b. Both windows should stay at 60 fps
5. Close the WebGL demo window
   a. After 10 seconds the you will automatically switch to the
      integrated GPU (gfxCardStatus should switch to saying 'i' again)
   b. The poster circle window should stay at 60 fps
The critical parts of this test are the 60 fps parts in 4.b and 5.b. It
will be the case that there will be a pretty hard hiccup for up to a
second, but after 2-3 seconds, it should stabilize back to 60 fps.

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

Cr-Commit-Position: refs/heads/master@{#305918}