* feat(local-video): convert to react

- Create a VideoTrack component for displaying a video element.
  This mirrors native also having a VideoTrack component.
- The VideoTrack component does not let React update it to prevent
  the video element from re-rendering, which could cause flickers
  and would not work with temasys's overriding of the video element.
- VideoTrack extends AbstractVideoTrack to mirror native
  implementation and to get the dispatch of the onplaying event.
- Remove the onclick handler on the video element. Honestly, I
  didn't get it to work, and did not try, but it is also unnecessary
  because another handler already exists on the video wrapper.

* ref(device-selection): VideoInputPreview uses VideoTrack to show video

* squash into conversion: change css selectors

* squash into conversion: mix in abstract props

* squash into conversion: change shouldComponentUpdate check

* squash: update comment about why triggerOnPlayingUpdate is used

Dynamically enables/disables the toolbar video button. Prior to that
commit if we would start with no video there would be no way to enable
it later on.

The files styles.js are used (pretty much) on React Native only and each
of them exports 1 name. Export it as default to cut down on source code.

Introduce certain React Components which may be used to write
cross-platform source code such as Audio like Web's audio, Container
like Web's div, Text like Web's p, etc.

It's now natively supported:
https://github.com/oney/react-native-webrtc/pull/244

Use the curstom _switchCamera API provided by react-native-webrtc to toggle the
camera instead of destroying the current track and creating a new one.

_switchCamera is implemented at a low level, so the track perceives no changes,
thus being a lot faster and less involved since the capturer doesn't need to be
destroyed and re-created.

In addition, don't mirror the video for the back camera.

Ref: https://github.com/oney/react-native-webrtc/pull/235

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

React Native provides Platform.

Redux actions which represent "commands" should be imperative, and those
representing events should use the past tense.

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.

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.