* fix: Fixes loading recommendedBrowsers page.

Fixes loading the page and its resources when using html base (cdn).

Reason:
- This is easier overridable than then embedded react page
- Consistenty between IE and other unsupported browsers

It should read "Chrome or Firefox" not "Chrome and Firefox", as you only need to use a single browser, not both.

* Update recommended browser links to https

* Update browser URLs to https

* Configurable (sub)optimal and unsupported browsers

* maybe this helps somehow

For the most part the changes are taking the "static propTypes" declaration off
of components and declaring them as Flow types. Sometimes to support flow some
method signatures had to be added. There are some exceptions in which more had
to be done to tame the beast:
- AbstractVideoTrack: put in additional truthy checks for videoTrack.
- Video: add truthy checks for the _videoElement ref.
- shouldRenderVideoTrack function: Some component could pass null for the
  videoTrack argument and Flow wanted that called out explicitly.
- DisplayName: Add a truthy check for the input ref before acting on it.
- NumbersList: Move array checks inline for Flow to comprehend array methods
  could be called. Add type checks in the Object.entries loop as the value is
  assumed to be a mixed type by Flow.
- AbstractToolbarButton: add additional truthy check for passed in type.

Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.

This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.

In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:

- JitsiMeetJS initialization is now synchronous: there is nothing async about
  it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
  support can now be detected immediately, so take advantage of this to simplify
  how we handle unsupported browsers. See [0].

The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.

[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779

WebRTC plugin support has been axed, this is now dead code.

* feat(Deeplinking): Implement for web.

* ref(unsupported_browser): Move the mobile version to deeplinking feature

* feat(deeplinking_mobile): Redesign.

* fix(deeplinking): Use interface.NATIVE_APP_NAME.

* feat(dial_in_summary): Add the PIN to the number link.

* fix(deep_linking): Handle use case when there isn't deep linking image.

* fix(deep_linking): css

* fix(deep_linking): deeplink -> "deep linking"

* fix(deeplinking_css): Remove position: fixed

* docs(deeplinking): Add comment for the openWebApp action.

Do not include the protocol part in the intent URL.

For the static page an error message displays stating no room
was specified. On mobile for unsupported browsers, the dial in
info will not show.

- Move the existing components for the static dial in page into
  a separate folder for easier reuse.
- Reuse those components for displaying dial-on numbers on the
  mobile page for unsupported browsers.
- Modify those components to support having tel protocol
  links on the dial-in numbers.
- Have DialInSummary, formerly DialInInfoPage, respect a
  passed in className prop for easier styling differences.

Prepare for React 16.

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

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.

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

The desired behavior of the button 'Start a conference' / 'Join the
conversation' is to launch the mobile app if installed; otherwise, do
nothing i.e. continue to display UnsupportedMobileBrowser.

Anyway, we may change our minds about allowing the user to continue in a
supported mobile browser so preserve the source code that enables that
but give it more appropriate naming.

React Native provides a Platform abstraction which React does not
provide.