Move root window notifications to WebView

This is a change to the public interface of Toolkit.  Instead of notifying
Toolkit whenever a root window receives WM_WINDOWPOSCHANGED and
WM_SETTINGCHANGE, this commit makes it so that each WebView needs to be
notified whenever the root window hosting it receives these messages.

Normally, chromium adds a hook on the root window to automatically detect when
the root window receives these messages.  However, this only works if the root
window was created in the browser-main thread.  For blpwtk2, we previously had
it so that this hook was disabled when 'RENDERER_MAIN' thread mode is used,
because in that situation, the root window thread would be different from the
browser-main thread.

In this commit, we changed this so that we always disable the hook, regardless
of the thread mode.  This is in preparation for supporting multiple blpwtk2
client processes, because in that situation, the root window thread would be
different from the browser-main thread, even if 'ORIGINAL' thread mode was
used.

We will now send an IPC message to the browser-main thread whenever the WebView
is notified about these events (previously, we just PostTask'd to the
browser-main thread).
Move NC drag support out to WebViewDelegate

This removes the NC drag implementation from blpwtk2.  Instead of handling NC
drag events internally, the WebViewDelegate is now notified about NC drag
events so that the application can handle them.

In this cleanup, we remove a bunch of PostTasks between the application thread
and the browser-main thread.  This will make it easier to have multiple client
processes.
Support externally managed processes in RenderProcessHostImpl

In order to support both in-process and out-of-process renderers at the same
time, we previously added a flag in RenderProcessHostImpl to indicate whether
it was used for an in-process or an out-of-process renderer.

In order to implement multi-process mode, we will need to have three possible
modes for RenderProcessHostImpl:

* spawned out-of-process: This is the normal chromium mode where
                          RenderProcessHostImpl spawns and manages a separate
                          renderer process.
* in-process: This is the mode we introduced for blpwtk2 where the renderer
              runs in-process with the browser-main.
* unspawned out-of-process: This is a new mode we want to introduce where the
                            renderer runs in a separate process, but isn't
                            spawned or managed by RenderProcessHostImpl.

To make RenderProcessHostImpl support this, this commit replaces the
'is_in_process' boolean flag with a 'externally_managed_handle'.  This is the
process handle where the renderer will run.  If the handle is null, then
RenderProcessHostImpl will spawn and manage the renderer process (like normal
Chromium).  If the handle is the same as the current process, this means the
RenderProcessHostImpl is using an in-process renderer.  If the handle is
something else, that means the renderer is running in a separate process that
is not spawned or managed by RenderProcessHostImpl (e.g. a separate blpwtk2
client process).
Rename InProcessRendererHost to ManagedRenderProcessHost

This is in preparation for supporting multi-process mode, where we will have
renderers running in externally managed processes (each process being a blpwtk2
process client).

Normally, chromium creates RenderProcessHostImpl objects whenever new renderers
are needed, and automatically cleans them up when the attached RenderViewHosts
are detached.  A ManagedRenderProcessHost creates a RenderProcessHostImpl on
construction and cleans it up on destruction.  This allows blpwtk2 to control
its lifetime, rather than having chromium automatically destroy it.

Note that an in-process renderer host is just a special kind of managed
renderer host where the renderer's process handle is equal to the current
process handle.
Use separate RendererInfo for in-process renderers

In order to support renderers running in separate blpwtk2 clients, we need each
blpwtk2::ProcessHost to maintain its own RendererInfo.  This commit makes it so
that the RendererInfo for IN_PROCESS_RENDERER will not be stored in
RendererInfoMap (because it doesn't make sense at that scope).  It will now be
stored in ProcessHostImpl (for each blpwtk2 process client).  As a special
case, there is also a RendererInfo in ToolkitImpl that is used for the
in-process renderer in ORIGINAL thread mode (since there is no ProcessHostImpl
for this case).

Note that this commit also moves the implementation of obtainHostAffinity to
RendererInfoMap, which makes things a bit simpler.  This is only used when
renderer affinity is not IN_PROCESS_RENDERER.
Send in-process renderer channel using IPC

This is a new control message that will be sent to blpwtk2 process clients when
their ManagedRenderProcessHost has been initialized in the blpwtk2 ProcessHost.
This replaces the very specific mechanism that RenderProcessHostImpl used to
start the in-process renderer thread, with a much more general mechanism that
will also work when blpwtk2 process clients are running in separate processes.
Add multi-process support

This commit finally adds the ability for applications to use blpwtk2 in
multi-process mode.  What this essentially means is that multiple processes can
create WebViews, but they can all share the same browser-main.

A new 'createHostChannel' method has been added to Toolkit, and a 'hostChannel'
property has been added to ToolkitCreateParams.  Applications can call
'createHostChannel' to create a new channel.  This returns a 'hostChannel' that
can be passed to another (new) process.  The new process can use this
'hostChannel' when creating is Toolkit.  This establishes an IPC connection
between the new process and the browser-main used by the original process.

Note that the client process must use 'RENDERER_MAIN' thread mode (even if it
doesn't create in-process renderers).  If a 'hostChannel' is provided when the
Toolkit is created, then we will not create the secondary BrowserThread or
BrowserMainRunner.

There is a new 'ProcessHostManager' object that lives in the browser process.
It is responsible for cleaning up ProcessHost objects when the client processes
terminate.  It also destroys ProcessHosts that haven't been connected to within
an application-specified timeout (to prevent the channel being open
indefinitely).

Note that the blpwtk2 client process will (necessarily) force sandbox code to
be disabled.
Make shell support multi-process

The shell now has a "--host" parameter.  If set, the shell will host another
child shell process, which is the one that actually runs the app.

This commit also adds a "--in-process-renderer" flag, which can be used to make
the shell use in-process renderer.
Call ForceInProcessPlugins before starting the renderer thread

Doing it inside RenderProcessHostImpl does not work when the browser-main
thread is running out-of-process.  Also, this change ensures that the flag is
set before the renderer thread starts.
Remove HandleExternalProtocol methods that were added in content

This removes HandleExternalProtocol from:

* RenderViewHost
* RenderViewHostDelegate
* WebContentsDelegate

All these methods did was just forward calls from RenderViewHostImpl to
WebViewImpl through the chain of delegates.  This isn't necessary because we
can access the WebViewImpl directly inside our ResourceDispatcherHostDelegate
implementation.
Change WebViewDelegate::showTooltip to use StringRef

All string arguments passed to our delegates should use StringRef instead of
String.  Note that this is a change to the public interface of WebViewDelegate.
Replace HttpTransactionHandler with ResourceLoader

This commit removes the HttpTransactionHandler in favor of a much simpler
ResourceLoader.  The main problem with HttpTransactionHandler is that it works
in the browser-process, while our only use-case of it was to load resources
inside a blpwtk2 client process.

The new ResourceLoader interface is much simpler.  Note, however, that it only
works for in-process renderers and when using the 'RENDERER_MAIN' thread mode.
Allow usage of the same BrowserContextImpl for multiple clients

This commit makes it so that multiple blpwtk2 process clients can use the same
non-incognito BrowserContextImpl.  BrowserContextImplManager now manages
incognito and non-incognito browser contexts separately, so it can return the
same BrowserContextImpl is the dataDir matches a previously created
non-incognito browser context.

Note that the BrowserContextImpl::destroy() method is now a no-op, because the
BrowserContextImpl will be retained by BrowserContextImplManager until the
Toolkit is destroyed (so that it can potentially be reused by other processes).

Note that BrowserContextImplManager also retains incognito browser contexts.
This is temporarily necessary in order to workaround an upstream issue [1]
where requests are being made using unattached request contexts, causing CHECK
failures.

[1] http://crbug.com/90971
Add persistent cookie store

Although cookies were supported previously, they were not being persisted for
non-incognito profiles.  This commit fixes this issue.  ProfileCreateParams has
a new property to disable cookie persistence, if the application wants the
previous behavior.
Shell: Add command-line arguments for profile params
Shell: Always use an incognito profile for inspector

If a data directory is specified, use it only for storing web content, not
inspector resources.
Shell: Add command-line argument for custom tooltip
Rename enableSystemPlugins to disablePluginDiscovery

This is a change to the public interface of ToolkitCreateParams.  This makes it
so that we match the name of the feature that was introduced in chromium 29.

Also, add a "--no-plugin-discovery" command-line flag to the shell to control
this behavior.
Destroy ProcessHostManager before destroying browser contexts

This ensures that remote processes will not be able to create browser contexts
while the host is shutting down.
Merge remote-tracking branch 'origin/feature/blpwtk2/29.0.1547.76' into release/candidate