Prepare ApplicationService for multiple applications handling.

Prepare ApplicationService for multiple applications handling: ApplicationService now owns a ScopedVector of Applications.
Application::Observer class is introduced so that application can notify about its termination and deletion.
Application::Launch methods return a pointer to the corresponding Application instance, ApplicationSystem methods are modified accordingly.
Merge pull request #1388 from pozdnyakov/Prepare_for_multi_app

Prepare ApplicationService for multiple applications handling.
[Runtime] Move XWalkExtensionService to XWalkRunner

It was previously created in XWalkBrowserMainParts, moving it to
XWalkRunner, which now will contain the main subsystems and tie them
together.
[Runtime] Add OnRenderProcess{Created,Gone} to XWalkRunner

RenderProcessHost lifecycle is important for XWalkRunner because some of
the subsystems in Crosswalk are implemented in terms of Crosswalk
extensions or have Crosswalk extensions as part of the interface.

Every time a new Render Process (Host) is created (which in Crosswalk
should be equivalent to a new application running), we have a proper
hook to create the extensions for that application in XWalkRunner.
[Runtime] Add platform specific subclasses of XWalkRunner

This is a preparation for moving the extension creation to
XWalkRunner (and its subclasses). Eventually I expect to be able to nuke
the XWalkBrowserMainParts variants, so all "platform specific"
behavior (at least with regards to initialization) will be in
XWalkRunner subclasses.

An interesting point: for the same reasons XWalkRunner::Get() exists,
the XWalkRunnerAndroid::Get() and XWalkRunnerTizen::Get() also exists. I
added a note reinforcing that they should be used with care, but it's
best to have a clear way to reach the top objects (and expose things
when a platform needs) instead of making ad-hoc solutions.
[Runtime] Add virtuals in XWalkRunner to register extensions
component
tmp
tmp
tmp
tmp