[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.
[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
automatically.

In the JavaScript shim, is important to use "internal.postMessage" so it will
use the Internal Extension callback system. 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.
[SysApps] Implement the Device Capabilities getStorageInfo()

This patch implements the bits for retrieving the storage information. The
returned object has just static information for now and won't notify storage
events.
[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] Add the SystemStorage object implementation

The SystemStorageObject is the native part of the SystemStorage object
living in the JavaScript. It will be in charge of relaying all the
storage added/removed notifications as events to the JavaScript shim.

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 SystemStorage dispatch events

This is probably this most tricky part. SystemStorage has already a native
counterpart, but the JavaScript shim is not really aware of that. This is how we
make this happen:

The first thing to be done is make the JavaScript SystemStorage 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.

In this case, the object was initially created in the native side, so we have to
comunicate this ID to the JavaScript shim. For that, I new wrapper around the
promise had to be created.

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.

Finally, on the JavaScript side, SystemStorage is now an object that with a few things on
the constructor.

- common.BindingObject.call(this, object_id) will initialize the BindingObject
and stablish the "link" for routing the messages.
- common.EventTarget.call(this) initializes the EventTarget and makes
this._addEvent() possible.
- 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 SystemStorage,
freeing resources.

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] Implement the Device Capabilities getMemoryInfo()

This is probably the easiest to implement and the most portable API. It could be
implemented without a "provider", but let's just keep using the pattern to make
the implementation more coherent.

We are using the Chromium abstractions, so it should work on all platform
supported by Chromium with no need of provider abstractions.
[SysApps] Add a simple test for Device Capabilities

Not to self: make a browsertest out of this. :)