[Runtime] Add CSP supporting for Crosswalk scheme

The CSP control will be enabled in packaged application by adding the
CSP content into the Crosswalk scheme response header.

The CSP policy is coming from "content_security_policy" field in
manifest.json, so web application developer could configure it as they
want.

https://crosswalk-project.org/jira/browse/XWALK-630
[Runtime] Disable the default CSP policy

Remove the default CSP policy: script-src 'self'; object-src 'self',
since it will block many tests and applications.
[SysApps][Android] Add permission to app template for Contact API

BUG=https://crosswalk-project.org/jira/browse/XWALK-778
Merge pull request #1424 from deqing/add_permission

[SysApps][Android] Add permission to app template for Contacts API
Application extensions support multiple applications

Application extensions are now provided with corresponding Application instances.
The corresponding application instance is found by Render Process Host (RPH) associated with it
(There's one-to-one correspondence between Application and RPH, obtained from its "runtimes").

RPH id getter is added to Application class. ApplicationService can lookup an application by the RPH id.
The rest of changes in the Application class (and all changes in Runtime class) are caused by the necessity for the application
to be aware of the associated RPH id before its first "Runtime" loads anything.
Merge pull request #1417 from takethathe/csp_protocol

[Runtime] Add CSP supporting for Crosswalk scheme
Merge pull request #1415 from pozdnyakov/Extensions_support_multi_apps

Application extensions support multiple applications
[Tizen] Install support files for "run as service" mode

This commit adds to the installation the support files for D-Bus and
systemd to make Crosswalk auto activated by D-Bus and managed by
systemd (in the user session). The xwalkctl and xwalk-launcher
applications should be used to interact with service mode.

Crosswalk is installed as a systemd user service, named
xwalk.service. To check it's status, you can use (always with app user
on Tizen 2.x)

    $ whoami
    app

    [ Because shell via sdb doesn't set the right D-Bus session address,
      we need to set it manually because systemctl uses it. Our xwalk
      tools on Tizen will automatically find the right address. ]

    $ export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/app/dbus/user_bus_socket
    $ systemctl --user status xwalk.service

Other regular systemd commands (restart, stop, start) should work as
well. Because of D-Bus auto activation feature, Crosswalk doesn't need
to be manually started. Just invoke xwalkctl or xwalk-launcher, and
Crosswalk will be started behind the scenes.

In service mode, the logs of Crosswalk go to systemd's "journal". You
can check that by using (as root, at the moment)

    [ Trick to show more information ]

    # export COLUMNS=1000
    # systemd-journalctl _COMM=xwalk

For debugging it might be useful to directly run Crosswalk (to use gdb
or other tools), in that case, stop the current running Crosswalk using
'systemctl --user stop xwalk.service' and run xwalk binary directly
passing '--run-as-service'.

For now, we still support the current (non-service) way of using
Crosswalk. To avoid conflicts in the configuration files, we use a
different data directory (in $HOME). This means that we have different
app database, so do not expect apps installed in one way to work in
another.

Once we make sure service mode is running OK, we plan to remove the
current way of using Crosswalk (at least on Tizen)

- remove the "xwalk --install and --uninstall" switches;
- remove the "xwalk" script from $PATH;
- and then make the service mode default.

What is still missing in service mode is support for the Tizen-specific
steps of the installation (making the installed app appear on the
homescreen) and tighter integration with Tizen task switcher. Those will
come in following patches.
Revert "Fix compilation error with -Werror=delete-non-virtual-dtor flag set"

It turns out my checkout was probably outdated at the time I got this
warning, as GCC 4.8 does not complain about this anymore.

This reverts commit 01c4780c6ecd9901f965ded475e8f9b638738921.

Conflicts:
	runtime/browser/xwalk_browser_main_parts.cc
Disable NoCSP unit test

Disable NoCSP unit test as the default CSP policy settings in CSP manifest handler
were removed (since they had affected some tests and legacy apps).
The test shall be enabled again when we have default CSP settings back.
Merge pull request #1427 from pozdnyakov/Disable_NoCSP

Disable NoCSP unit test
Merge pull request #1425 from rakuco/revert-unneeded-gcc48-fix

Revert "Fix compilation error with -Werror=delete-non-virtual-dtor flag set"
Merge pull request #1412 from cmarcelo/run-as-service

[Tizen] Install support files for "run as service" mode
[Application] Fix build warning - unused variable

This object don't need a variable
Merge pull request #1429 from ricardotk/minor-fix

[Application] Fix build warning - unused variable
Bump version to 4.32.63.0
[Runtime] Save registered events information in ApplicationData if
the Application is launched by unpacked path.

Crosswalk supports launching unpacked application without install
the application first, and this is the same with current browsertests.

To make these types of applications able to handle registered events,
a solution is to save the events information in ApplicationData when
executing the main document. Events for these applications will not be
saved in ApplicationStorage.
[Runtime] Make sure event observers are released before event manager.

ApplicationEventManager must be destroyed later than the EventObserver.
Otherwise, the event_manager_ will be a wild pointer in EventObserver
destructor.
[Runtime] Add browsertest for onSuspend Event API.