[SysApps] Add the Storage Info data provider abstraction

This data provider was implemented differently from the CPU Info data provider.
I'm expecting the platform implementation to be more complex, so this is just an
interface.

The platform implementation should inherit from StorageInfoProvider and
provide a implementation of the static method GetInstance(). This will allow
the StorageInfoProvider[Windows|Tizen|Linux|...] to have its own attributes
and methods.
[SysApps] Make StorageInfoProvider observable

Add the Observer interface so other objects can get notifications when
a new storage is attached and detached.

It is important to remember that StorageInfoProvider must be a singleton,
so different webapps will share the same provider. This way, we don't waste
resources monitoring the same environment twice.

The provider will get a notification to start monitoring when the first observer
is added and another notification to stop monitoring when the last is removed.
[SysApps] Add a mock StorageInfoProvider

This is just a mock info provider emulating how a provider will behave in a real
life. When monitoring for file system events, it will add and remove a storage
every 1s. It will also report at least 3 non-removable storages when asked.
[SysApps] Implement the Device Capabilities getStorageInfo()

This patch implements the bits for retrieving the storage information. This is
not very diffirent for the getCPUInfo other than it is using a different
provider.
[SysApps] Add an method for checking if an Event is active

This is probably more straightforward than keeping booleans around
to check if there are listeners for a certain event.
[SysApps] Make DeviceCapabilitiesObject an EventTarget

This patch adds the native bits of the EventTarget. This will allow
DeviceCapabilitiesObject to get notifications when there is someone listening
for events, so we can start monitoring the filesystem by adding an observer.

It is important to notice that it will only add itself as an observer to the
StorageProviderInfo when there is actually some listener in the JavaScript side,
this way we don't do any monitoring if nobody is listening.

The EventTarget class triggers the StartEvent() method when the first listener
is added and the StopEvent() when the last listener is removed for a particular
event.
[SysApps] Make the JavaScript shim dispatch events

The first thing to be done is make the JavaScript DeviceCapabilties an EventTarget
(which is also a BindingObject). The BindingObjects are JavaScripts objects with
a link with some native object and they use a unique ID for routing messages
between them.

common.EventTarget.call(this) initializes the EventTarget and makes
this._addEvent() possible.

Now all the blanks are filled and we are good to go. The next step would be
replace the StorageInfoProviderMock with a real implementation for each platform
we support. No need to touch on anything else.
[SysApps] Added StorageProvider unit tests
[SysApps] Added getStorageInfo() browsertests
Merge pull request #1461 from tmpsantos/devcap_storage

[SysApps] Implement the Device Capabilities getStorageInfo()
[Application][Tizen] Move the installation steps into a new file

When running Crosswalk on Tizen in the 'run-as-service' mode we use
the new installation mode, that only a small binary will run as root.
[Packaging] Set the install helper tool as 'set-user-ID-root'

This will allow this tool to finish the last pieces of the installation
of an application: copying the icon to the right place and adding the
application meta-data to the central application database (via a XML
file that is also kept in a central place).
[Application][Tizen] Simplify the installation steps

We can keep the application binary (that will be a link to the xwalk-launcher)
binary inside a user created directory (data_dir), this allows for some
simplification.

Error are printed in the standard output, so the 'GetAppOutputWithExitCode()'
can print bettter error messages if installation/uninstallation fails.
[Application][Tizen] Change the effective UID of the application to 'root'

When adding the application metadata to the application
database (pkgmgr_parser_parse_manifest_for_installation), it is
required that the process has 'root'(0) UID so the
installation/uninstallation can proceed.
[Application][Tizen] Exit the application when the TERMINATE event is received

If we want the application to quit after it is terminated via the
Tizen task manager, we need to handle this event.

As Crosswalk will be following the unique name of the launcher process
and will kill the appropriate application when its launcher exits the
D-Bus session bus, simply calling exit() is enough.
[Application][Tizen] Be more tolerant of the parameters passed to xwalk-launcher

When the application is launched via the Tizen application
launcher (or via launch_app), it will be launched with more parameters
than we actually care, but if its argv[0] is a valid application ID,
that's all that we need.
[Application][Tizen] Separate paths for potencial conflicts

In the cases that we install files in the same path that the "old" way
would, use 'xwalk-service.'  prefix to keep these cases apart avoid
messing with old installations.
[Application][Tizen] Install a default crosswalk icon if no icon is provided

If the application being installed doesn't provides an icon, we install the
default Crosswalk icon as the icon for that application.