[Tizen][SysApps] Add AVCodecs support in device capabilities

The main idea is as below:
1. Get supported codec and mime format list from libffmpegsumo.so
2. Use APIs in net/base/mime_util.h to verify whether a format/codec supported.
   If true, the codec will be added in the supported media codecs list.

The step 2 logic refers to implementation of
WebKit::WebMimeRegistry::supportsMediaMIMEType()

spec: http://device-capabilities.sysapps.org/
feature: https://crosswalk-project.org/jira/browse/XWALK-47
[Application][Linux] Expose interface for launch apps via D-Bus

The exported object '/running/' supports only one method in its
interface, that is used to Launch applications. The ObjectManager based
interface will come in future patches, once the notion of "running
application" is added to Crosswalk (Mikhail / Alex work).

At the moment, Crosswalk quits after the application window is closed,
even running as a service. This behavior will change in future
patches.
[Applications][D-Bus] Emit InterfacesAdded signal when app is installed

When a object is added to the bus we send all its properties (following the
ObjectManager recommendations) re-using most of the code that was added
for implementing the GetManagedObjects() call.
[Applications][D-Bus] Emit InterfacesRemoved when app is uninstalled

Even if our clients won't use this Interfaces, it may be useful for
debbuging purposes and for completeness of our implementation of
the D-Bus ObjectManager interface.

There was the need for the PropertyExporter object to export in
which interfaces it has properties.
Merge pull request #1118 from qjia7/getAVCodecs

[SysApps][Tizen] Add AVCodecs support in device capabilities
Merge pull request #1225 from vcgomes/xwalk-dbus

[Applications][D-Bus] Emit InterfacesAdded and InterfacesRemoved signal
Merge pull request #1211 from cmarcelo/dbus-launch-app

[Application][Linux] Expose interface for launch apps via D-Bus
[Runtime] Register event router when launching application by app ID.

Currently the event router is not registered if we launch application by
application ID method.

This PR is to fix above issue, besides it refactors Launch() methods
inside application service.
Merge pull request #1226 from shaochangbin/app-launch

[Runtime] Register event router when launching application by app ID.
[SysApps] Do not build Device Capabilities for Tizen and Android

Otherwise it will clash with the new implementation.
[SysApps] Add a stub for the Device Capabilities API

This patch adds the basic bits for starting the development of the
Device Capabilties API:

- The IDL files to generate the data serializers.
- The JavaScript shim file, initializing the internal extension system
- An Extension class and an Instance class.
- Register the extension on the XWalkBrowserMainParts (only desktop ATM).
[SysApps] Add an data provider abstraction for the CPU information

The data provider will access the underlying platform and fill a SystemCPU
struct. We are using Chromium classes to retrieve this information, which is
platform independent. In the following patch we will be adding a platform
specialization for querying the CPU load.

Note that the SystemCPU struct is not defined anywhere. By adding SystemCPU dictionary
interface to the IDL file, we instruct the generators to generate the header and
code for this struct, also a function to serialize the struct as a message we can send to
the JavaScript shim.
[SysApps] Add platform dependent CPU info providers

The buildsystem will handle the compilation units accordly to the suffix. No
compile time guards (#ifdefs) are necessary here.

The Windows implementation is just a no-op stub.
[SysApps] Add a wrapper to make Promise work with Internal Extensions callbacks

Promises are a really nice fit with the Internal Extensions callbacks, because
they are single shot (you fire it once and forget about it).

We just need to create a wrapper around it with a "protocol" so we can
properly call fulfill() or reject() depending on the message we get from
the native backend.

The Internal Extension callback system will handle keep tracking of the mapping
between callback handlers in the native side and pending Promises in the
JavaScript shim automatically.
[Extensions] Make it possible to export an object

Currently the JavaScript shim receives an object "export" which you are supposed
to add properties. But what if you want to export an object created in the shim
istead? This patch adds exactly that: now, by returning an object, it gets exported
at the root of the API namespace instead of the "export" object.
[SysApps] Add the Device Capabilities Object

Usually, we could be handling static methods at the Instance object, but this
API requires an EventTarget (coming soon) which adds a bit of complexity,
that's why we need an Device Capabilities Object.

DeviceCapabilitiesInstance has now a BindingObjectStore, which is a class for
keeping track of BindingObjects lifecycle and routing messages. It will
automatically destroy BindingObjects when they are no longer used and route
messages to objects based on the unique ID.

In the JavaScript side we have:

common.BindingObject.call(this, object_id) will initialize the BindingObject
and stablish the "link" for routing the messages.

this._registerLifecycleTracker() will make use of one V8 extensions we have that
implements a sort of destructor. When the SystemStorage is collected by the GC, it
will send a message to the native side, which will be handled by the
BindingObjectStore that will destroy the native part of the
DeviceCapabilties, freeing resources.

DeviceCapabilities  is being exported at the root of the API namespace and cannot
be created with "new". We have only on instance of this object per app.

In the JavaScript shim, returning an object makes it the root of the API namespace.
[SysApps] Implement the Device Capabilities getCPUInfo()

We first add an callback and function to the IDL to make it generate the Promise
reply serializers, which contains the SystemCPU + error message if applicable.

A function handler for "getCPUInfo" is also needed and it will associate the
message coming from the extension with a class method. It is being registered in
the Instance constructor.

GetCPUInfo::Results::Create is generated from the IDL. This function will
create a message which the promise wrapper will receive.

info->PostResult() has internally the callback ID that maps to a callback ID in
the JavaScript shim, so the message will reach the correct recipient.

In the JavaScript shim, is important to use "this_.postMessage" so it will
wrap the Binding Object routing ID automatically to the message. The "[]"
stands for the getCPUInfo arguments, which is empty in this case.
[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] Added 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.

We could reuse this later for unit tests.