[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] Make entry points info available to the ModuleSystem

If we want to support loading extensions on demand, we have to make the
information for which entry points each extension will be accessible to
the entity responsible for loading extensions, in our case, the entity
is XWalkModuleSystem.
[Extensions] Add a way to tag extensions that will be loaded on demand

For now we will use a simple algorithm that will only load "leaf"
extensions on demand, for example, if "tizen", "tizen.time" and
"tizen.power" are in the extension list, we will enable loading on
demand for "tizen.time" and "tizen.power".
[Extensions] Load extensions on demand

Now that we have all the pieces it is time to put them together.

For each extension marked as 'should use the trampoline', we setup
"trap" acessors (for all entry points), that when run will load the
extension and create an instance for it. Before the extension is
loaded we need to remove all the references to the accessor function,
so it is not run anymore for those objects.
Bump version to 2.31.23.0
[Add] Add new APIs to XWalkClient for renderer responsiveness

This fix is to add 2 new APIs to XWalkClient for renderer
responsiveness. Internally, xwalk will start a timer to check if the
renderer become unresponsive if no ACK message for handling input event
is received from the renderer in 30 seconds. In this case, the callback
onRendererUnresponsive will be called. If it becomes responsive again,
the callback onRendererResponsive will be called.

BUG=https://github.com/crosswalk-project/crosswalk/issues/913
TEST=org.xwalk.core.xwview.test.RendererResponsivenessTest
Merge pull request #914 from hmin/unresponsive-handler

[Add] Add new APIs to XWalkClient for renderer responsiveness
Merge pull request #967 from vcgomes/load-on-demand

[Extensions] Load extensions on demand
[Extensions] Fix race condition in Extensions registering.

Nowadays we are facing a race condition between the moment
we get the first XWalkExtensionRendererController::DidCreateScriptContext()
for a given RenderProcess and the moment we register the external extensions
at XWalkExtensionRendererController's external_extensions_client_.

This patch fixes this by inverting the registration order. Now
during the Client's initialization we synchronously ask the Server
for the extensions to register.

In addition to that, XWalkExtensionProcessMsg_RegisterExtensions
has also become a Sync message so we can guarantee all external
extensions have been loaded way before doing anything else on
the BrowserProcess (more specifically at
XWalkExtensionService::OnRenderProcessCreated()).