Link chrome_blpwtk2 into blpwtk2.dll
Fix false positive/negative resize_ack_pending_ in RenderWidgetHostImpl

This is:
  https://chromiumcodereview.appspot.com/18413004
Move generated version files to SHARED_INTERMEDIATE_DIR
Fix signed/unsigned comparison warning
Fix inconsistent coding style
Add support for zooming

Add ability to set zoom percent for the WebView where 100 is the
"original size" or 100%, 150 is 150% etc. up to default limits of
500% and 25% of original size, respectively.
Add support for find-on-page feature

Find text on the current page. To clear highlighted results send an
empty search string. Sending the same search string again implies
continuing the search forward or backward depending on the value of
the third argument.
Add .rc files for product version information
Add blpangle target

This commit adds a new 'blpangle' target that contains libEGL and libGLESv2, so
that we can deploy them as a single versioned module.  However, we still want
to build libEGL and libGLESv2 as separate DLLs so that they can be used by
content_shell.

To do this, we needed to split the 'libEGL' and 'libGLESv2' targets into shared
and static libraries, and change 'libEGL' to a 'loadable_module' so that its
import library is never linked into any projects.

'libGLESv2' cannot be converted to 'loadable_module' because 'libEGL' needs to
link to it.  To prevent its import library from being linked into any other
projects, all other references to it have been removed.  The target has also
been renamed to 'libGLESv2_shared' to prevent future Chromium updates from
adding it as a dependency.

The DllMain from these dlls perform important thread-local-storage setup.  To
use this in a static_library, rename the DllMain functions to 'libEGLMain' and
'libGLESv2Main'.  These functions will be called from blpangle's DllMain.
Also, new dllmain.cpp files have been added to the 'libEGL' and
'libGLESv2_shared' targets.  The new DllMain functions just invoke the
'libEGLMain' and 'libGLESv2Main' functions that are in the static libraries.

The previous main.cpp files also defined an 'error' global function, which have
been renamed to 'libegl_error' and 'libglesv2_error' in order to prevent
potential conflicts in the combined blpangle module.

The code that loads these dlls is in src/ui/gl.  It loads the DLLs and obtains
the eglGetProcAddress function.  However, for blpwtk2, we want it to load the
versioned blpangle DLL instead.  A new 'SetBLPAngleDLLName' function has been
added to src/ui/gl so that we can give it the DLL name.  If the blpangle DLL
name has been set, then src/ui/gl will load the blpangle DLL instead and obtain
the 'blpangle_getProcAddress' function, bypassing libEGL.dll and libGLESv2.dll
entirely.

On the blpwtk2 side, a few things need to be done:
* Create a blpangle target that links 'libEGL_static' and 'libGLESv2_static'.
* DllMain for blpangle needs to call 'libEGLMain' and 'libGLESv2Main'.
* We need to implement a custom get-proc-address procedure.  It needs to be
  able to return the address of all the egl* and gl* functions that are
  exported by 'libEGL' and 'libGLESv2'.  In order to do this, we generate a
  binding file that implements the get-proc-address procedure, using the
  functions defined in the .def files for these dlls.  We use the function
  definitions in src/ui/gl's generate_bindings.py to obtain the function
  signatures.
Support NC dragging in RENDERER_MAIN thread mode

In upstream chromium, the only way to support non-client dragging was to add a
"transparent region" using 'RenderWidgetHostViewWin::SetClickthroughRegion'.
However, this requires the application to compute this region upfront, which
may be non-trivial for complex UIs.  In addition to this, it does not work with
RENDERER_MAIN thread mode, because HTTRANSPARENT in Windows does not propagate
the hit test across threads.

This commit introduces a new callback in WebViewDelegate that allows the
application to do its own hit testing.  The WebView implementation on the
browser thread will always use its most recently known hit test result.  Note
that there may be a lag in this result, but this seems to be negligible.  The
browser thread does its best to keep up by re-requesting the hit test if it
detects that the mouse coordinates have moved.

On the chromium side, the WebContentsViewWin now handles the necessary Windows
NC events and allows the WebContentsDelegate (implemented by WebViewImpl) to
perform the drag.
Synchronize moving in-process WebViews when on the main thread

When resizing windows that contain WebViews, there is a noticable lag between
when the window resizes, and when the web content is repainted.  This lag is
especially noticable for complex web UIs.

This patch attempts to reduce this lag by blocking WebView::move() until the
contents are ready to be painted.  Note that right now, this only works with
WebViews that are running in-process on the main thread.

When running in this mode, we disable browser-side resizes from being
propagated to the renderer because, since we will always originate the resize
from the main thread, we can avoid a roundtrip to the browser thread and back
if we just notify the renderer about the resize while we are already in the
main thread.  This requires the WebViewProxy to know upfront that it is running
in-process, rather than discovering that fact after the document loads.  When
WebViewProxy::move() is called, we dispatch the sync move request to the
browser thread, resize the RenderView, and wait for an ack that the browser
thread has updated its backing store with the new size.

Note that this patch removes the 'repaint' parameter in WebView::move() because
it turns out to be meaningless in the context of multi-threaded paint updates.

Our previous attempt in the "Buffer WebViewProxy::move() calls" commit handled
the case where we get a backlog of move requests, but did not handle the issue
where the main window resizes out-of-sync with the WebView.  This patch
supersedes that attempt.
Don't include base/basictypes.h from npapi.h

This include makes the header unusable from plugins that are not in the
chromium source tree.  It doesn't seem to be actually needed by anything.
Always start the render thread

DRQS 46790563

The browser process in upstream chromium depends on a WebKit thread to be run
at startup.  This thread performs initialization of some WebKit data structures
(for example, text encoding data) that is used in the browser process.

For blpwtk2, we skip running this WebKit thread in favor of an in-process
renderer thread, which does the same initialization.  In a previous commit,
titled "Create in-process renderer only when it is used", we deferred the
creation of the renderer thread until the first in-process WebView was created.
This has caused crashes in applications that do not create in-process WebViews,
if they accessed content that required browser-side access to the WebKit data
structures.  This commit fixes the issue by creating the renderer thread on
startup, instead of waiting for the first in-process WebView.

One complication that arises since the introduction of Profile is that we
cannot create the in-process renderer host until we know which profile is going
to be used for in-process WebViews.  However, content's RenderThreadImpl
requires the channel of the in-process renderer host to be provided at
construction time.

To fix this, RenderThreadImpl (and the ChildThread base class) has been
modified to be able to defer creation of the channel if it receives an empty
channel name at construction.  Any MessageFilters added to RenderThreadImpl
will be placed in a queue until the channel is created.

The channel will be created when the channel name is determined, which happens
when the in-process renderer host is created, which happens if/when the first
in-process WebView is created.

Another complication is that the flag that controls whether in-process plugins
should be used for in-process renderers is now unknown at the time the
in-process render thread is constructed, because this is also determined when
the first in-process WebView is created.  We work around this by re-checking
the flag once we get the channel name (at which point, we know that an
in-process WebView has been created).

With this change, we also revert the following commit, because it is no longer
an issue:

    ef6ca76 "Disable RenderViewHostImpl::CanAccessFilesOfSerializedState"
Add API to configure max sockets per proxy

This just configures the static properties in the net module.  Note that
setting the max sockets per proxy to something lower than the default max
sockets per group will also reduce the max sockets per group.  This is because
we must maintain the invariant that max sockets per group should never exceed
max sockets per proxy.
Multiple languages for spellcheck

Let kSpellCheckDictionary be a comma-separated list of languages, so we load a
vector of Hunspell dictionaries for each profile.

The spellchecker first checks for misspellings in the first language.  If it
finds a misspelled word, it looks in the other languages to see if that
misspelled word is found there.  Suggestions are accumulated from all
languages.

Also, fixed a bug where the custom dictionary was not always being checked.
Add kSpellCheckCustomWords user preference

For blpwtk2, we want to be able to programatically provide a list of custom
words, instead of loading custom words from a file on disk.  This commit adds
support for this by checking if we have registered a user pref for custom
words.  If this user pref is not registered, then the regular file-based custom
words dictionary will be used.
Add a way to disable downloading dictionaries

By default, chromium downloads dictionaries if it does not find them installed
in the dictionary directory.  For blpwtk2, we don't want it to download
dictionaries.
Perform spellcheck locally, and enable autocorrect

Instead of using the online spellcheck service, just run spellcheck using the
installed dictionary.  Also, don't require kEnableSpellingAutoCorrect on the
command-line because this setting comes from the user prefs.
Land spellchecking in blpwtk2

Spellchecking is off by default, and can be enabled by configuring the blpwtk2
Profile with a SpellCheckConfig object.  Spellcheck suggestions are provided in
the context menu params, and WebView now exposes a method to replace misspelled
words.

Note that the upstream chromium code really wants a PersistentPrefStore.
Instead of modifying all that code, we just use a dummy PrefStore class that
implements PersistentPrefStore, but doesn't really persist the user prefs.
Note that blpwtk2, by design, does not persist profile settings, and relies on
the application to configure the Profile object appropriately at initialization
time.
Refactor find-on-page code and fix a minor bug

Factor out find-on-page code duplicated in WebViewImpl and WebViewProxy
classes into the FindOnPage class instantiated on demand either in
WebViewImpl or in WebViewProxy depending on the thread mode.

Clear cached match count and active match index (ordinal) when the
search string changes.