trimmed release 32.0.1700.107
Rebase 'feature/blpwtk2' from upstream/31.0.1650.63 onto upstream/32.0.1700.107

Conflicts:
	src/blpwtk2/blpwtk2.gyp
	src/build/gyp_blpwtk2
	src/chrome/browser/printing/printing_message_filter.cc
	src/chrome/renderer/spellchecker/spellcheck.cc
	src/content/browser/frame_host/interstitial_page_impl.cc
	src/content/browser/renderer_host/render_widget_host_view_win.cc
	src/content/browser/site_instance_impl.cc
	src/content/browser/web_contents/web_contents_view_win.cc
	src/content/browser/web_contents/web_contents_view_win.h
	src/content/child/child_thread.cc
	src/content/child/child_thread.h
	src/content/content_tests.gypi
	src/content/public/renderer/content_renderer_client.cc
	src/content/public/renderer/content_renderer_client.h
	src/content/renderer/render_thread_impl.cc
	src/content/shell/browser/shell.cc
	src/content/shell/browser/shell.h
	src/content/shell/browser/shell_content_browser_client.cc
	src/ipc/ipc_channel_proxy.h
	src/third_party/WebKit/Source/core/core.gypi
	src/third_party/WebKit/Source/core/dom/Document.cpp
	src/third_party/WebKit/Source/core/dom/Document.h
	src/third_party/WebKit/Source/core/dom/Document.idl
	src/third_party/WebKit/Source/web/ChromeClientImpl.h
	src/third_party/WebKit/Source/web/WebElement.cpp
	src/third_party/WebKit/public/web/WebDocument.h
	src/third_party/WebKit/public/web/WebElement.h
	src/third_party/WebKit/public/web/WebNode.h
	src/third_party/angle_dx11/src/build_angle.gypi
	src/v8/tools/gyp/v8.gyp
Fix compile errors for v32, integrate with Aura

* 'glue' and 'glue_child' have been moved to webkit_glue.gyp
  (https://chromiumcodereview.appspot.com/23583055)
* 'blink_common' has been moved to blink_platform.gyp
  (https://chromiumcodereview.appspot.com/25195003)
* Remove reference to libGLESv2 in compositor.gyp (this is a new gyp file that
  we started depending on in v32)
* New MIDI overrides in BrowserContext
  (https://codereview.chromium.org/38043004)
* BrowserMessageFilter no longer derives from IPC::ChannelProxy::MessageFilter
  (https://codereview.chromium.org/24514003)
* New parameter in ContentRendererClient::GetNavigationErrorStrings
  (https://codereview.chromium.org/24503004)
* DevToolsHttpHandlerDelegate now must implement target discovery
  (https://codereview.chromium.org/24995003)
* Revert r228757 upstream (https://codereview.chromium.org/27183007).  This was
  a change to delete the in-process RenderProcessHost.  This isn't needed for
  us because blpwtk2 already manages the RenderProcessHost lifetime.
* There is a new SpellChecker class, and now the spellcheck methods in Editor
  are private.  So use the new SpellChecker class instead
  (https://codereview.chromium.org/26565013)
* WEBKIT_EXPORT has been renamed to BLINK_EXPORT
  (https://codereview.chromium.org/24515002)
* Fixed ManagedRenderProcessHost to remove dependency on content impl classes
  (these caused compile failures because of new non-exported dependencies).
  Moved the createRenderProcessHost implementation into the content module (in
  content::RenderProcessHost)

This commit also updates blpwtk2 to integrate with Aura:
* Added 'blpwtk2::ViewsDelegateImpl', which is currently a copy of
  content_shell's 'ShellViewsDelegateAura'
* Added 'blpwtk2::NativeViewWidget', which wraps a views::Widget to contain a
  'gfx::NativeView' (i.e. an aura::Window*), and make the widget a child or the
  HWND provided by the application
* Updated 'blpwtk2::WebViewImpl' to host the content::WebContents inside a
  blpwtk2::NativeViewWidget
* Fix compositor.gyp to not reference libGLESv2 (this was a new file added for
  Aura builds, so it was left out in [1])
* No longer need disableHookOnRoot, since Aura doesn't setup those hooks
* Add ui_resources.rc so that we can get scrollbar resources

[1] cd4217d "Add blpangle target"
Remove WebContentsDelegate::OnSetCursor

This method was added in [1], and implemented in blpwtk2::WebViewImpl.
However, it is no longer necessary because 'HWNDMessageHandler::OnSetCursor'
now does the same thing.

[1] 57efad7 "Support NC dragging in RENDERER_MAIN thread mode"
Periodically PeekMessage when sending sync messages

This is only enabled on the application's main thread in RENDERER_MAIN mode.
It is necessary to handle the situation where an HWND in the browser-main
thread (i.e. the aura native widget) is parented into an HWND in the renderer
thread (i.e. an application's window in the application's main thread).  This
can cause the browser-main thread to be blocked on a Windows sent message (due
to interactions between the two HWNDs).  If the renderer is in the middle of a
sync IPC message, this causes a deadlock between the two threads.

This commit resolves this issue by making the renderer thread wake up
periodically when it is waiting for the sync IPC reply.  Whenever it wakes up,
it will flush any sent messages on the Windows message queue (using the
PeekMessage function), which lets the browser-main thread continue executing.
Use base::StaticAtomicSequenceNumber for layer IDs in cc::Layer

Ref: https://codereview.chromium.org/313823002
Fix unsafe threading in CachedProgramInfoManager::DeleteInfo

Ref: https://codereview.chromium.org/171713002
Separate WGC3D sharegroup sets per channel

Ref: https://codereview.chromium.org/35503004
Fix possible use-after-free in WGC3D shared context map

Ref: https://codereview.chromium.org/102823002
Don't assert that WindowClosing is only called once

It can be called twice if the HWND receives WM_DESTROY twice.  This can happen,
for example, if the HWND is parented into a window on another thread, which
receives WM_DESTROY, and at the same time, the browser-main thread destroys the
HWND.  The second WM_DESTROY comes from the parent window's thread, which sends
WM_DESTROY to all its children.
Make tree id sequence in LayerTreeHost thread-safe

Ref: https://codereview.chromium.org/57713004
     https://codereview.chromium.org/60353002
Fix an invalid assertion in WebViewImpl::FindReply

The check for RENDERER_MAIN is no longer valid with the multi-process model,
since we might be in ORIGINAL mode, and be hosting a WebViewProxy that lives in
another process.
Fix command-line for in-process renderers

Ref: https://codereview.chromium.org/57463011
     https://codereview.chromium.org/129633002
Pickup 'feature/blpwtk2' updates from upstream/31.0.1650.63 into upstream/32.0.1700.107
Fix command-line for in-process renderers in client processes

In a previous commit [1], the command-line for in-process renderers was fixed
to pass the necessary gpu-related command-line switches.  However, this only
worked for in-process renderers that were in the same process as the
browser-main.

This commit fixes the case where an in-process renderer is created in a
separate blpwtk2 client process.  This requires modifying the CommandLine in
the client process, which means that the command-line switches need to be
somehow transported from the host process to the client process.

This is a problem since we cannot use IPC for this, because the IPC channel is
only setup once threads have started, at which point, we cannot safely modify
the global CommandLine object in the client process.

To solve this, this commit changes the result of 'Toolkit::createHostChannel'
from returning a channel-id string, to instead return a "channel-info" string,
which is a base64-encoded blob containing the channel-id and the command-line
switches.  The client process can then decode this blob and add the switches to
its global CommandLine object before starting any threads.

Note that this doesn't require any changes to applications that are using
'Toolkit::createHostChannel', as long as applications correctly transport the
base64 string to the client process.  The 'Toolkit::createHostChannel' return
value was always meant to be an opaque blob that gets passed to
'ToolkitCreateParams::setHostChannel', without being interpreted by the
application in any way.

[1] 6e515a4 "Fix command-line for in-process renderers"
Automatically show WebViews created via 'WebContentsCreated'

This is to be consistent with the behavior prior to the switch to Aura.  In
pre-Aura, the WebContentsView HWND was visible by default.  However, in Aura,
the NativeWidget HWND is invisible by default.  This causes WebViews created
using 'window.open' to be invisible because applications never needed to call
'show()' in the past.  So let's just call 'show()' internally so that they
don't have to.
Treat focus changes as activation changes for child windows

When integrating with Aura [1], it was decided to use DesktopNativeWidgetAura
(with the WS_CHILD style added), instead of using NativeWidgetAura, because the
desktop version seemed more complete, and it is what is actually used by
content shell.

However, all the focus stuff for DesktopNativeWidgetAura is handled in the
window activation codepath.  This caused focus to be broken for us because our
child HWND was receiving WM_SETFOCUS and WM_KILLFOCUS, instead of WM_ACTIVATE.

This commit solves this issue by treating WM_SETFOCUS and WM_KILLFOCUS as
window activation changes whenever the DesktopNativeWidgetAura is really a
child window.

[1] 1433f6d "Fix compile errors for v32, integrate with Aura"
Fix some blpwtk2 features for Aura

The referenced features stopped working in Aura because the Windows-specific
parts of the changes were missing in Aura.  This commit fixes that.

[1] 8f31279 "Add option to disable SetFocus on mouse down"
[2] 8b2384a "Add WebViewDelegate::blurred"
Respond to WM_SETCURSOR when the cursor is in the client area

Ref: https://codereview.chromium.org/96943004
Fix HWNDMessageHandler::OnSetCursor handling of HTERROR

Ref: https://codereview.chromium.org/284313016