Add application extension and getManifest(), getMainDocument() API support

The application extension is an internal extension to handle application level
APIs(e.g., runtime events, manifest, package management, etc.).

In this commit two APIs is added, one is xwalk.application.getManifest(see
http://developer.chrome.com/apps/runtime.html#method-getManifest), the other is
xwalk.application.getMainDocument(see
http://developer.chrome.com/apps/runtime.html#method-getBackgroundPage).

We use asynchronous calls for both of these two APIs. getManifest() will
retrieve current running application's manifest dictionary value and post the
value to renderer. getMainDocument() utilizes ApplicationNativeModule to get
RenderView from the main document's routing ID, then return its main frame
global JS object.
Bump version to 2.31.20.0
Add application browser test base class and application API browser test

ApplicationBrowserTest is a base class for application browser test. Currently
it only provides Runtime status check. It will support other application test
utilities after shared browser process model is supported.

In this commit getManifest() and getMainDocument() API tests are added.
Bump chromium-crosswalk in DEPS.xwalk.

Bring in the fix in chromium to fix the rendering issue
of content shell when using single process on Android.
Merge pull request #923 from wang16/roll_deps

Bump chromium-crosswalk in DEPS.xwalk.
Merge pull request #612 from seanlong/xiang_api

[Runtime] Add application extension skeleton and getManifest, getMainDocument API support
[Extensions] Refactoring XWalkExtensionService::RegisterExtension

Nowadays our XWalkExtensionService is only capable of handling
one RenderProcess. Thus, it only has one in_process XWalkExtensionServer
for handling internal extensions. Soon enough this will considerably
change and we will have to be capable of handling one in_process
XWalkExtensionServer per RenderProcess.

This patch is the first step towards this: internal extensions
will be created directly by the XWalkExtensionService::Delegate
"on-demand" every time a new in_process XWalkExtensionServer
is created for a new RenderProcess and it is time to register
the internal extensions on it.

The entity implementing XWalkExtensionService::Delegate is
XWalkBrowserMainParts. This way we keep the old behavior and design
not polluting XWalkExtensionService.

Necessary adjustments were made to RegisterExtensionsCallback and
browser_tests for the same reason.
Enable multithreaded GPU compositing of web content by default.

Enable multithreaded GPU compositing of web content by default, this also enables pinch gesture support on Tizen.
Merge pull request #933 from pozdnyakov/EnableThreadedCompositing

Enable multithreaded GPU compositing of web content by default.
[Extensions] Remove unused function
[Extensions][Android] Make CreateExtension call XWalkExtensionService directly

XWalkBrowserMainParts is now a XWalkExtensionService::Delegate, meaning that
XWalkExtensionService will call RegisterInternalExtensionsInServer everytime
a new in_process XWalkExtensionServer is created (for a new RenderProcess).

Therefore, XWalkExtensionService::RegisterExtension() has been removed
and XWalkExtensionAndroid will now need to register its extensions on
XWalkBrowserMainParts so them can get correctly registered on-demand
by XWalkExtensionService.
Merge pull request #934 from cmarcelo/remove-dead-code

[Extensions] Remove unused function
[Extensions] Use a vector instead of a map for extension modules

In XWalkModuleSystem, use a vector instead of a map for extension
modules. The number of modules is small and we'll benefit from being
able to easily get sorted iteration later to identify the extension
modules that can be loaded on demand.
Merge pull request #910 from jeez/refactor-register-extension

[Extensions] Refactoring XWalkExtensionService::RegisterExtension
Merge pull request #937 from cmarcelo/extension-modules-vector

[Extensions] Use a vector instead of a map for extension modules
[Extensions] Add SetExtraEntryPoints to Extension C API

This will allow for Extension to inform if they have other entry
points (apart from the implicit extension_name), that should cause
the extension to be loaded.

For example, the "calendar" extension may export some constants in the
CalendarAppointment object, and we want the calendar extension to be
loaded when any of these "main" objects are accessed.
[Extensions] Add tests for loading extension with multiple entry points

This test verifies that the extension is loaded even if the entry point
is in a different object than the one implicitly created by the extension
name.
[Extensions] Verify that the entry points are valid names

Also make sure that there aren't any extension already registered
with clashing names (or entry points).