It renders a single JitsiMeetFragment which holds the JitsiMeetView view.

In practice, we are never going to be in a position where we don't have a
ReactContext but we do have some React Native code running. So let's not expect
the impossible.

It was never used and typicallt the Activity / Fragment holding the
JitsiMeetView object will be the listener.

In addition, once we refactor the events they will be reduced into far fewer.

That's what the SDK passes now, if the room URL is not absolute.

Co-authored-by: Saúl Ibarra Corretgé <saghul@jitsi.org>

There is no need for AbstractApp to require some getWindowLocation function.
It's only used in one place and we even polyfill it on mobile.

Thus replace it's usage with more specific functions.

Since the SDK may be embedded with other apps, we need to recognize our custom
URL scheme and universal links in order to tell the user if we will process the
request or not.

Make them configurable with sane defaults.

It's now all handled in the SDK an we'll get the new URLs via props.

Add JitsiMeetFragment and refactor the app to use it.

- cleanup
- API simplification (single loadURL method)
- JitsiMeet singleton for linking helpers and globals
- Linking moved to app

* Updates recording dialog.

* Update config.js doc.

* Adds comment and make a check more intuitive.

* Changes of using enum for recording types.

The android.telecom.CallAudioState class was only added in API level 23 (Android
M), so make sure we don't import it in lower versioned devices.

* feat(screenshare): emit source type when starting screenshare

* squash: update doc

Bring over two fixes for spot. One is for
identifying the screenshare type when using
a camera for screenshare or when using a proxy
stream. Also bring in a fix to avoid a js error
in chrome ios.

* Adds integrations doc.

Google, Microsoft and Dropbox for now.

* Updates doc.

Seems like windows does not have emojis for flags.