The Device Selection modal consists of:
- DeviceSelection, an overly smart component responsible for
  triggering stream creation and cleanup.
- DeviceSelector for selector elements.
- VideoInputPreview for displaying a video preview.
- AudioInputPreview for displaying a volume meter.
- AudioOutputPreview for a test sound output link.

Store changes include is primarily storing the list of
available devices in redux. Other app state has been left
alone for future refactoring.

When a conference is to happen in a domain which is not the defaut, its config
is loaded and set. As part of this process, lib-jitsi-meet is disposed. Because
disposing is asynchronous, events happen in this sequence:

- set new config
- dispose lib (which effectively wipes the config)
- init lib

This results in the library to be initialized without the loaded config, which
was lost. This commit fixes that by delaying setting the config and
re-initializing the library until it was disposed.

They better represent if a participant has video available or not. There are
cases when even a participant in the last N set would not have video because it
disconnected momentarily, for example.

The error raised by JitsiMeetJS.init() is already in the state of
features/base/lib-jitsi-meet so it's not a good design to store the same
error in the state of features/unsupported-browser.

Includes automatic recommended Xcode project file fixes.

Lib-jitsi-meet uses jQuery's .append method to manipulate Jingle. The
method in question invokes the getter and setter of Element.innerHTML.
Unfortunately, xmldom which we use in React Native to polyfill DOM does
not polyfill Element.innerHTML. So polyfill it ourselves.

Turns out React Native's timers (setTimeout / setInterval) don't run while the
app is in the background: https://github.com/facebook/react-native/issues/167

This patch replaces the global timer functions with those from the
react-native-background-timer package, which work in the background.

These timers won't magically make an application work in the background, but
they will run if an application already happens to run in the background. That's
our case while in a conference, so these timers will run, allowing XMPP pings to
be sent and the conference to stay up as long as the user desires.

Until we make a decision on access modifier hints and adopt a respective
coding style, consistency is king.

React Native provides Platform.

The audio levels are gathered by lib-jitsi-meet via polling of
RTCPeerConnection.getStats() which is very slow on Android. Since the
mobile app makes no use of audio levels, it is easiest to disable them
for now in order to not penalize the app.

The toolbar's mute buttons depict respective features/base/media states.
However, (un)muting is practically carried out by features/base/tracks.
When the mobile app enters a conference configured to invite the joining
participant to mute themselves, the tracks would be muted but the
toolbar's mute buttons would not reflect that.

jitsi/lib-jitsi-meet#66b601e disabled the execution of Temasys'
adapter.screenshare.js on browsers on which we don't use Temasys such as
React Native. Henceforth, no Temasys workarounds are necessary on React
Native.

As a step toward merging jitsi-meet-react with jitsi-meet to share as
much source code as possible between mobile and Web, merge the part of
jitsi-meet-react's source tree which supports mobile inside the
jitsi-meet source tree and leave jitsi-meet-react's Web support in the
source code revision history but don't have it in master anymore because
it's different from jitsi-meet's Web support. In other words, the two
projects are mechanically merged at the file level and don't really
share source code between mobile and Web.

As an intermediate step on the path to merging jitsi-meet and
jitsi-meet-react, import the whole source code of jitsi-meet-react as it
stands at
2f23d98424
i.e. the lastest master at the time of this import. No modifications are
applied to the imported source code in order to preserve a complete
snapshot of it in the repository of jitsi-meet and, thus, facilitate
comparison later on. Consequently, the source code of jitsi-meet and/or
jitsi-meet-react may not work. For example, jitsi-meet's jshint may be
unable to parse jitsi-meet-react's source code.