* Javadoc introduced @code as a replacement of <code> and <tt> which is
  better aligned with other javadoc tags such as @link. Use it in the
  Java source code. If we switch to Kotlin, then we'll definitely use
  Markdown.

* There are more uses of @code in the JavaScript source code than <tt>
  so use @code for the sake of consistency. Eventually, I'd rather we
  switch to Markdown because it's easier on my eyes.

* Xcode is plain confused by @code and @link. The Internet says that
  Xcode supports the backquote character to denote the beginning and end
  of a string of characters which should be formatted for display as
  code but it doesn't work for me. <tt> is not rendered at all. So use
  the backquote which is rendered itself. Hopefully, if we switch to
  Markdown, then it'll be common between JavaScript and Objective-C
  source code.

It provides access to the app's display name and version.

* Regardless of whether the SDK client/consumer employs
  JitsiMeetActivity or JitsiMeetView, default to finishing the
  associated Activity upon invoking the back button (which is what
  Activity#onBackPressed() is documented to do).

* Do not break the public API of JitsiMeetView and, thus, Jitsi Meet SDK
  for Android.

If the JS side chooses to not handle the back button press call
'super.onBackPressed()' to close the app.

Don't require autofocus because that prevents the app from appearing in
Google Play Store for some devices.

Don't require camera for the same reason but also because camera/video
is not a mandatory feature of the app, it's merely likely very
desirable.

The class ReflectiveOperationException used in ExternalAPIModule was
introduced in API level 19.

JitsiMeetViewListener is an integral part of the public API of Jitsi
Meet SDK for Android. Utilize it in the Debug configuration of the Jitsi
Meet app for Android in order to increase (1) awareness of API breakages
and (2) API coverage.

The same goes for JitsiMeetViewDelegate in Jitsi Meet SDK and app for
iOS.

The error is stored in the redux store in base/config so other components can
consult it. It is also broadcasted as a new event in the external API for the
SDK.

JitsiMeetViewListener currently has methods of one and the same pattern
so adding new methods i.e. events i.e. redux action types is a question
of repetition in the Java source code. Speed up the support of new
events by trying to deal with them in a generic way.

The same goes for JitsiMeetViewDelegate.

It's a global action, and if we do that other applications won't be able to use
it. I experienced this with the system camera. We do, however, make sure to
enable it when we need to.

Note that enabling it doesn't mean we are *using* it. It just means we *can*,
and that we will get actual audio when we do.

Avatars are cached to the filesystem and loaded from there when requested again.
The cache is cleaned after a conference ends and on application startup
(defensive move).

In addition, implement a fully local avatar system, which is used as a fallback
when loading a remote avatar fails. It can also be forced using a prop.

The fully local avatars use a user icon as a mask and apply a background color
qhich is picked by hashing the URI passed to the avatar. If no URI is passed a
random color is chosen.

A grace period of 1 second is also implemented so a default local avatar will be
rendered if an Avatar component is mounted but has no URI. If a URI is specified
later on, it will be loaded and displayed. In case loading the remote avatar
fails, the locally generated one will be used.

In iOS this is automagically done in the view destructor, bunt we don't have
that luxury in Java we have to do it manually.

The new disponse() method MUST be called when the Activity holding the view is
going to be destroyed, typically in the onDestroy() handler.

Introduces loadURLObject in JitsiMeetView on Android and iOS which
accepts a Bundle and NSDictionary, respectively, similar in structure to
the JS object accepted by the constructor of Web's ExternalAPI. At this
time, only the property url of the bundle/dictionary is supported.
However, it allows the public API of loadURLObject to be consumed. The
property url will be made optional in the future and other properties
will be supported from which a URL will be constructed.

Initializing a new URL/NSURL instance is a chore especially when one
takes into account that the JavaScript side (1) is loading the URL
asynchronously and (2) is capable of parsing strings that may or may not
be represented as URL/NSURL.

The Android method loadURLString(String) may have been called
loadURL(String) to overload loadURL(URL) but I didn't want to do that
because:

1. It would not be compatible with existing source code such as
loadURL(null) which would have become ambiguous.

2. I wanted to achieve better convergence with the iOS API.

This was already an implicit requirement, as it's the only version implemented
in libwebrtc.

The reason to add this is to (defensively) try to filter old devices which may
not implement it.

WebRTC's own Android demo app defines this.

This reverts commit c9a29153dd.

Now that react-native-webrtc supports the permissions system in 23, use it since
it provides a more pleasant experience to users.

In addition, fix a bug in the previous code: the React Native view must be
loaded after we have acquired the permission to draw on top of other apps,
otherwise our app may crash while we accept the permission, since React may try
to draw.

API level 22 is below 23 (aka Marshmallow), which included an overhaul in the
permissions system. React Native recommends 22 (it's the default when you create
a new app) and there have been reports when set higher [0] and [1].

This also fixes a critical bug, wherein Jitsi Meet wouldn't request permissions
for the camera and microphone.

Last, this change also allows us to get rid of the overlay checking code,
because it was only needed for API level 23 or higher.

[0]: https://github.com/facebook/react-native/pull/10479
[1]: https://github.com/facebook/react-native/issues/10587

Also expose this in the native SDKs.

Copy it from the main fonts directory instead.

Changing the props from native (Java) code was only added in 0.45, so add a
workaround until we get to updating our React Native dependency.

The current implementation doesn't use the API and Transport modules. This is
due to the fact that they are too tied to APP at the moment, which is web only.

Once API is refactored and moved into the Redux store this will be adjusted,
though it's unlikely that the lowest level React Native module (ExternalAPI)
changes drastically.

This commit also introduces a stopgap limitation of only allowing a single
instance for JitsiMeetView objects on both Android and iOS. React Native doesn't
really play well with having multiple instances of the same modules on the same
bridge, since they behave a bit like singletons. Even if we were to use multiple
bridges, some features depend on system-level global state, such as the
AVAudioSession mode or Android's immersive mode. Further attempts will be made
at lifting this limitation in the future, though.

Dames en heren, welcome to Jitsi Meet SDK for Android, the Jitsi Meet library
for Android.

The Jitsi Meet SDK encapsulates React Native and all the dependencies Jitsi
Meet has so other aopplications can integrate it easily.

Unlike iOS, creating "fat" libraries is not allways (if at all) possible on
Android, however, effort was put into making the integration as easy as
possible.

While React Native can be embedded in native applications, I don't think it was
designed to be embedded as part of an Android library, hidden away from the
application using it. This surfaced as a number of issues which had to be
addressed specifically due to our use-case:

- Activity lifecycle methods must be linked with the React Native engine, so the
  library provides wrapper methods.
- Custom fonts have to be manually added as assets, since the provided gradle
  script doesn't work properly in a library target.
- The RN packager has to be manually triggered since the gradle script will no
  longer do it for us.

At this stage, the Jitsi Meet application is just a small single activity
application which uses the Jitsi Meet SDK to create a single activity which
represents the entire application. Events and external conference handling are
forthcoming.

PS: Yours truly would like to add that it was a lot more fun to work on the iOS
side of things.