Add -bb-rubberbandable CSS property

DRQS 37714496

This property will allow us to control, on a per element basis, whether or not
text within the element participates in rubberbanding.  The property is
inherited, and if any RenderText has it evaluate to "text", then the
RenderText's contents will be considered when rubberbanding.  If it evaluates
to "none", then the RenderText will be ignored during the rubberband process.
Implement rubberbanding

DRQS 37714496

There are two ways to enable rubberbanding:
* automatic mode
* manual mode

In the automatic mode, the client calls 'enableAltDragRubberbanding(true)' and
this enables code in WebView's mouse handler to automatically perform
rubberbanding when the user does Alt+Mousedrag.  The WebViewClient will be
notified with the new rubberband rectangle whenever the mouse moves.  Text will
be copied to the clipboard automatically on Alt+Mouseup.

In the manual mode, the client is responsible for handling the mouse events,
but WebView exposes methods to expand rectangles to enclose text, and to obtain
the text contained within a given rectangle.

The bulk of the rubberbanding implementation is contained in a separate
WebViewImplRubberband.cpp file.  This contains code that walks the render tree
to determine absolute position of text boxes, taking into account
transformations, clipping etc.  Note that we don't walk layers that have
transforms other than scale and translate.

When getting the text contained within a rectangle, we use some basic
heuristics to determine which text boxes are on the same line, then sort them
from left to right, adding an appropriate amount of spaces to fill the gaps
between them.

Also, TestShell has been modified to use the automatic mode.
Merge remote-tracking branch 'origin/feature/rubberband/26.0.1410.43' into feature/rubberband/28.0.1500.95

Conflicts:
	chromium/src/third_party/WebKit/Source/WebCore/css/CSSComputedStyleDeclaration.cpp
	chromium/src/third_party/WebKit/Source/WebCore/css/CSSParser.cpp
	chromium/src/third_party/WebKit/Source/WebCore/css/CSSPrimitiveValueMappings.h
	chromium/src/third_party/WebKit/Source/WebCore/css/CSSProperty.cpp
	chromium/src/third_party/WebKit/Source/WebCore/css/CSSPropertyNames.in
	chromium/src/third_party/WebKit/Source/WebCore/css/StyleBuilder.cpp
	chromium/src/third_party/WebKit/Source/WebCore/css/StyleResolver.cpp
	chromium/src/third_party/WebKit/Source/WebCore/rendering/style/RenderStyle.cpp
	chromium/src/third_party/WebKit/Source/WebCore/rendering/style/RenderStyle.h
	chromium/src/third_party/WebKit/Source/WebCore/rendering/style/RenderStyleConstants.h
	chromium/src/third_party/WebKit/Source/WebCore/rendering/style/StyleRareInheritedData.cpp
	chromium/src/third_party/WebKit/Source/WebCore/rendering/style/StyleRareInheritedData.h
	chromium/src/third_party/WebKit/Source/WebKit/chromium/public/WebViewClient.h
	chromium/src/third_party/WebKit/Source/WebKit/chromium/src/WebViewImpl.cpp
	chromium/src/webkit/tools/test_shell/test_webview_delegate.h
	chromium/src/webkit/tools/test_shell/test_webview_delegate_win.cc
	chromium/src/webkit/tools/test_shell/webview_host_win.cc
	chromium/src/webkit/tools/test_shell/webwidget_host.h
	chromium/src/webkit/tools/test_shell/webwidget_host_win.cc
Rename ProfileImpl to ProfileProxy

Previously, ProfileImpl was our only implementation of Profile, and it just
posted the config structures to the browser-main thread.  We would do this even
in the 'ORIGINAL' thread-mode.

In this commit, we renamed ProfileImpl to ProfileProxy (following the same
naming scheme used for WebViewProxy), and changed BrowserContextImpl to also
implement the Profile interface.

So in the 'RENDERER_MAIN' thread-mode, we will create a ProfileProxy that posts
the config structures to the BrowserContextImpl in the browser-main thread.
But in the 'ORIGINAL' thread-mode, we will just create a BrowserContextImpl and
return that to the application.

Also, ProfileManager has been replaced with BrowserContextImplManager.  We no
longer need to keep ProfileProxy objects alive until threads stop, so they now
just get deleted when they are no longer referenced.  The BrowserContext
lifetime is a bit more complex though, because they are still being referenced
by some objects (for example, the in-process renderer host), even after the
application destroys the Profile.  The BrowserContextImplManager will be used
temporarily to keep the BrowserContextImpl objects alive until the browser-main
thread has finished pumping messages.  Once we cleanup all the post-'destroy()'
references to BrowserContext, we can get rid of BrowserContextImplManager and
let the BrowserContextImpl objects get deleted inside destroy().
Add ProcessHost and ProcessClient

This is in preparation for supporting blpwtk2 clients in multiple processes.  A
ProcessHost will be created in the browser-main thread, for each blpwtk2 client
process.  This creates a new IPC channel that will be used to communicate with
a ProcessClient, which will be created in the application-main thread in each
blpwtk2 client process.  Note that right now, the ProcessHost and ProcessClient
interfaces are identical, but they will diverge over time.

When using the 'RENDERER_MAIN' thread mode, we will create 'in-process'
ProcessHost and ProcessClient objects.  In subsequent commits, we will change
ProfileProxy and WebViewProxy to use the IPC channels provided by ProcessHost
and ProcessClient, instead of directly posting tasks between threads.

Once the ProfileProxy and WebViewProxy conversion is complete, we can start
creating 'out-of-process' ProcessHost and ProcessClient objects, which will
finally allow blpwtk2 clients to live in multiple processes.
Make ProfileProxy use IPC instead of PostTask

This is a largely mechanical change, replacing the PostTasks in ProfileProxy
with IPC messages.  Profiles are created and destroyed using control messages,
handled by ProcessHost.  The ProcessHost creates a ProfileHost for each
ProfileProxy.

Note that right now, profile creation/destruction control messages are
synchronous.  This is only a temporary situation, and is necessary to ensure
that the BrowserContextImpl has been created before the WebViewProxy tries to
access it.  Once WebViewProxy has been converted to use IPC as well, then we
can change this to be asynchronous, and ProfileProxy will no longer need to
hold references to the BrowserContextImpl.

Also, in order to simplify the IPC param traits for ProxyConfig, we have
exposed references to the internal data members in some 'net' classes.

Also note that ProfileProxy no longer needs to be reference counted, since it
is no longer used in multiple threads.  ProfileProxy::destroy() will
immediately delete the object.
Make FindOnPage::Request a separate struct so it can be sent through IPC

This is a slight refactoring of FindOnPage::Request, which is used when
WebView::find() is called.  This commit makes it a simple struct, to simplify
the IPC implementation of WebView::find().  We also replace the usage of
'blpwtk2::String' with 'std::string'.

Also, the executeOn implementation has been moved to WebViewImpl.  This will
make it possible in the future to create a light-weight blpwtk2 dll for clients
that do not need in-process renderers.
Make Impl structs for ContextMenuItem and ContextMenuParams

This is a pimpl-ification of these two publicly exposed classes.  The Impl
structs use std::string and std::vector types, which makes them easy to use in
IPC param traits.  Also, the set* methods are no longer exposed, since these
are only ever used within blpwtk2.

This commit requires a change in the public interface because the methods that
previously returned 'blpwtk2::String' must now return 'blpwtk2::StringRef'
instead.
Remove WebViewDelegate::handleMediaRequest

This be being removed because:

* our WebRTC integration is no longer working (changes in upstream/latest since
  this feature was implemented have introduced new requirements).
* none of our apps are actually using this right now.
* it poses complications for the conversion to use IPC instead of PostTask.

WebRTC support can be added again later when necessary.  But for now, we will
remove it to simplify the IPC conversion.
Make WebViewProxy use IPC instead of PostTask

Like the IPC conversion for ProfileProxy, this is a largely mechanical change,
replacing the PostTasks in WebViewProxy with IPC messages.  WebViews are
created and destroyed using control messages, handled by ProcessHost.  The
ProcessHost creates a WebViewHost for each WebViewProxy.

Also like ProfileProxy, WebViewProxy no longer needs to be reference counted,
since it is no longer used in multiple threads.  However, we need to make it
support WeakPtr, because there is still a PostTask (to the current thread) in
'WebViewProxy::onAboutToNavigateRenderView'.
Move rendererAffinity -> hostAffinity conversion to BrowserMainRunner

This is just a refactoring of existing code to prevent it from being duplicated
in ProcessHostImpl and ToolkitImpl.  Creation of the InProcessRendererHost is
now handled entirely within BrowserMainRunner.
Use async messages for creating/destroying profiles

Now that WebViewProxy has been converted to use IPC, it no longer needs to
obtain the BrowserContextImpl from ProfileProxy, so we can make ProfileProxy
use async messages to create/destroy profiles.  ProfileProxy no longer needs to
hold a reference to BrowserContextImpl.
Add final sync control message before shutting down threads

This is necessary to ensure that all IPC messages have been handled by the
ProcessHost before shutting down the channel.  Otherwise, things like
BrowserContextImpl and WebViewImpl may not get destroyed properly.
Merge remote-tracking branch 'origin/feature/blpwtk2/29.0.1547.76' into release/candidate
Implement rubberbanding in content_shell

RenderViewHost now exposes EnableAltDragRubberbanding, which is called whenever
content_shell finishes navigating.  This enables rubberbanding on the
underlying WebKit::WebView.

The rubberband rect feedback is sent to the browser process and displayed using
a new RubberbandOutline class.
Merge version 29.0.1547.76_bb3

This version changes the internal implementation to be IPC-based, rather than
posting tasks between threads.  There are also changes to the ContextMenuParams
public interface to use StringRef instead of String.  Also, handleMediaRequest
has been removed from WebViewDelegate.
trimmed stable release 30.0.1599.101
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).