[Android] Implement the functions of application working from SD-Card.

  Crosswalk for Android port doesn't support the functions of application
moving to SD-card and working from SD-Card. This is because the AndroidManifest.xml
in xwalk app template doesn't support the application installation settings for
"preferExternal" or "Auto", and the corresponding intent actions should be registered
as response to the mounting and unmounting of SD-Card. This feature is to enable
the SD-Card related function supports.

BUG=https://crosswalk-project.org/jira/browse/XWALK-774
Add screen.onorientationchange event listener

The function set is fired whenever the orientation changes.
The test has been updated to count how many times the orientation
has changed so far.

The entries have been changed as there are some unresolved bugs
with the ondemand loading making this not work otherwise.
Merge pull request #1460 from kenchris/onorientation

Add screen.onorientationchange event listener
Bump version to 4.32.69.0
Merge pull request #1451 from ShDavidliu/RunningFromSD

[Android] Implement the functions of application working from SD-Card.
[Tizen] Register Application Extensions on Tizen.

Application Runtime Extension and Application Event Extension are not
registered on Tizen. This causes Runtime API and Event API don't work on
Tizen.

This PR fix the above issue.
Merge pull request #1465 from shaochangbin/register-module-tizen

[Tizen] Register Application Extensions on Tizen.
[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