[Runtime] Add XWalkComponent

This interface will be used by XWalkRunner to manage the subsystems and
call them in convenient times. Looking at current code of Crosswalk, the
following points are relevant for most subsystems:

- Before the main loop starts, for setting up any objects and shared
  data.

- When a new RPH (most of the time Application) is started, to register
  extensions.

- After the main loop ends, and we are about to be destroyed, to
  shutdown the subsystem.

In some cases only one of those matter, for example, experimental/dialog
only cares about registering extension. The idea is that any other
important hook should be added to XWalkComponent. That way, XWalkRunner
will mostly care about calling all the components in the sequence,
instead of knowing details about each subsystem.

Keeping an ordered sequence (like the ScopedVector) also makes it easy
to destroy the components in the reverse order of creation. The name
component was choosen based on the concept of "browser components" from
Chromium browser.

In the long run we should follow their example and, when possible, add
self-contained separated features into directories structured like
src/xwalk/components/feature/{renderer,browser,common}. That will make
runtime/ more focused on the basic runtime.
[Runtime] Create a component for Application subsystem

Even though it is a "special" component (because Application concept is
central to Crosswalk), we can benefit from the XWalkComponent interface
for hiding the details of the subsystem.

In this and next patches we'll see sometimes a little bit of
"redundancy" between the old entry point and the new XWalkComponent
subclass for each subsystem. This is being done like this to reduce the
amount of change to make component system work.

In the long run, some modules may simply adopt the component class as
their entry point. For other modules, that don't depend on runtime/,
there'll still be a separate XWalkComponent subclass in runtime/ to glue
things up.
[Runtime] Create a component for SysApps

This class is the glue between the XWalkRunner and the
SysAppsManager. The sysapps/ directoy doesn't depend on runtime/, so the
glue code is used instead of making SysAppsManager implement
XWalkComponent.

By overriding the factory method the Android and Tizen can configure
which extensions they need to disable, instead of manually creating the
RawSockets extension.

In the case of Tizen, we create a component just for the currently used
implementation of DeviceCapabilities -- a newer one is being implemented
and will replace it when achieve feature parity.