Over time features/base/util became a bucket where people seemed to dump
just about anything they couldn't think of a better place for. That's a
trend I don't like encouraging. Given that roomnameGenerator.js is
currently used in features/welcome only, I'm fine with moving it there
for the greater good.

jsdocs were added, remove old comment which no longer applies.

Split language detectors to be web/native dependent. Take care of strings that contain html.

When rendering using a for loop each child whould have a key prop.

Looks like Android gets confused as to what surface to blit when we hide or
show toolbars. Setting a border on the container, seems to force the entire
area to blit properly.

Other attempted approaches, with no success:
- zIndex of -100
- width and height of 0
- opacity of 0 and setting 'disabled' on touch containers

This patch applies the workaround in the welcome page and conference containers.

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

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

Recently, we reimplemented the Welcome page in React. Unfortunately, we
broke the checkbox that enables/disables the Welcome page and it would
allow checking but wouldn't allow unchecking.

Recently, we reimplemented the watermarks in React. Unfortunately, we
didn't take into account film strip-only mode.

Additionally, we duplicated watermark-related source code on the Welcome
and Conference pages.

This prevents the keyboard from showing up right when the app opens.

The React-based rewrite looks whether there's a room name (in the
window's location) in order to choose between WelcomePage and
Conference. But app.js expects Conference to be rendered before it
builds a room name if WelcomePage is disabled and there's no room name.
A quick and dirty workaround is to render Conference within WelcomePage
so that the rendered result closely resembles index.html before the
React-based rewrite.

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.