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

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.
[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_.addMethodWithPromise" so it will
wrap the Binding Object routing ID automatically to the message and associate it
to the Promise.
[SysApps] Add CPUInfoProvider unit tests

The test basically pings each entry point of the API and check if
the returns values are within a sane range.
[SysApps] Add browsertests for DeviceCapabilities getCPUInfo()

Not a replacement for W3C conformance tests, just checking the basic API
functionality and sanity. The test is crafted with the addition of tests
for the rest of the DeviceCapabilities API in mind, that is why we have
a test list with just one test.
[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] Compile Chromium's StorageMonitor as a module

The StorageMonitor is almost self-contained, despite adding itself
to the Chromium's Browser Process. We should work upstream to fix that.

Meanwhile we can compile it as module (and protect the Chromium specific bits
with a flag) so we can use it as backend for the Device Capabilities
getStorageInfo() for Linux, Mac and Windows.
[SysApps] Add a data provider for Linux based on Chromium's StorageMonitor

This provider has a big chance of being generic enough to be used for Mac and
Windows. The backend for Android was not implemented yet which makes me sad.

We will have to implement a custom provider for Android (upstream maybe?).
[SysApps] Add stubs for Android, Mac and Windows

For Mac and Windows we just "forward" to the Linux implementation. There is no
buildsystem rule that includes all the ports but no Android.

The Android implementation is just a no-op that should print "not implemented"
warnings.
[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] 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] Implement the Device Capabilities getDisplayInfo()

This provider is missing an Observer interface for notifications
of displays being connected and disconnected. This is very likely to
be platform dependent and we might need to add platform files.

Currently we only using a static method, but I'm keeping the GetInstance()
for the display monitoring implementation.
[SysApps] Watch for displays connections and disconnections

Using the Chromium's gfx:: abstractions on top of Screen and Display,
we can watch for new connections and disconnections in a portable way.

This patch also adds an observer interface to DisplayInfoProvider so
the DeviceCapabiltiesObject can subscribe to this events when necessary.
[SysApps] Dispatch display events to the JavaScript shim

Connect the bits from receiving a display connection/disconnection
event from the system to sending an event message to the JavaScript shim.

It is important to remember that the event is only triggered if there are
event listeners waiting for it.