Bump version to 3.31.39.0
Bump version to 3.32.39.0

This is all-in-one patch based on Chromium 32.0.1700.14, check each
commit at https://github.com/halton/crosswalk/commits/master_1700_14
Merge pull request #1141 from halton/all_in_one_32_0_1700_14

Bump version to 3.32.39.0
[Extensions] Add an ExtensionServer to the UI Thread

Currently for the in-process extensions, there is a separated thread
for running the extensions. This patch adds an ExtensionServer to the
existing UI Thread, which will allow extensions that interacts with
the UI or are limited because of main loop integration to run on the main
thread.
[Extensions] Make it possible to query an ExtensionServer for an extension

This function will be used to decide on which thread the extension has
to be created.
[Extensions] Route messages to the appropriated server

Based on the extension name and the extension ID, we route the messages
to the appropriated ExtensionServer running on the Extension thread or the
UI thread.

On the in-process extensions, 2 messages that are normally directed to the
ExtensionServer on the Extension Process are now completely handled by the
filter. One example is the GetExtensions message that has to combine a list
of available extensions from two different servers in a single reply.
[Extensions] Run external extensions on the UI Thread when single process

When using the single process mode, external extensions will run on the UI
thread by default. This is more compatible with the multi process mode where
the external extensions are running in the main thread of the Extension Process.
[Extensions] Run tests on the UI Thread by default

But keep hooks for running tests on the Extension Thread if need. Extensions
requiring IO main loop will need that.
[Extensions] Add browser tests for in-process extension threads

This test verifies if extensions registered to the UI Thread are
indeed running on the UI Thread. The same applies for extensions
registered to the Extension Thread.

We also test if messages (sync and async) are working on both scenarios.
[Extensions] Fix memory leak

ExtensionData was being removed from the map but the pointer was not
being deleted.
[Extensions] Move XwalkExtensionData to its own file

This patch simply move bits around. The idea is ExtensionData is
becoming to complex to the point it deserves to be self-contained.
[Extensions] Make XWalkExtensionData a class

Add getters and accessors to XWalkExtensionData and make its attributes private.
The most important aspect here is we move the logic of how to delete the
objects owned by XWalkExtensionData from the XwalkExtensionService back to
XWalkExtensionData, making the lifecycle more consistent.