NSURLConnection sendSynchronousRequest is deprecated since iOS 9. Replace the
method by whjat's currently on RN master, which implements a modern alternative.

This new version comes with an updated JSC runtime, so we no longer need to
depend on the updated version ourselves.

The app should always provide them.

Consolidate all failure cases into a single one: CONFERENCE_TERMINATED. If the
conference ended gracefully no error indicator will be present, otherwise there
will be.

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.

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

RTCAudioSession is a thin wrapper around AVAudioSession provided by the WebRTC
framework. It makes some use-cases easier, and leads us closer to manual audio
unit management, which we will likely need in the near future.

Fixes this issue:

Main Thread Checker: UI API called on a background thread: -[UIApplication setExpectsFaceContact:inLandscape:]
PID: 25442, TID: 10886619, Thread name: (none), Queue name: com.facebook.react.ProximityQueue, QoS: 0
Backtrace:
4   JitsiMeet                           0x000000010a0eaadc -[Proximity setEnabled:] + 64
5   CoreFoundation                      0x00000001fea34630 <redacted> + 144
6   CoreFoundation                      0x00000001fe912450 <redacted> + 292
7   CoreFoundation                      0x00000001fe913034 <redacted> + 60
8   JitsiMeet                           0x000000010a4e08e8 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 492
9   JitsiMeet                           0x000000010a4e7a10 _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicE + 248
10  JitsiMeet                           0x000000010a4e776c ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 88
11  libdispatch.dylib                   0x000000010b943824 _dispatch_call_block_and_release + 24
12  libdispatch.dylib                   0x000000010b944dc8 _dispatch_client_callout + 16
13  libdispatch.dylib                   0x000000010b94ce6c _dispatch_lane_serial_drain + 720
14  libdispatch.dylib                   0x000000010b94db60 _dispatch_lane_invoke + 460
15  libdispatch.dylib                   0x000000010b957bfc _dispatch_workloop_worker_thread + 1220
16  libsystem_pthread.dylib             0x00000001fe6490dc _pthread_wqthread + 312
17  libsystem_pthread.dylib             0x00000001fe64bcec start_wqthread + 4

We are going to implement the invite dialog *inside* the SDK, so there is no
need to have all this machinery anymore.

When we are in the default state (ie, not in a meeting) we shouldn't override
the AVAudioSession category and mode. It's a singleton and we might be bothering
other components of the host app which use it.

Load it at build time from a "dropbox.key" file. The file should contain the API
key in a single line.

This is mostly implemented in the app, with the needed support in the SDK. Since
the app needs to donate intents and deal with creating NSUserActivity objects it
doesn't feel right to do this in a library. Instead, we donate the intents from
the app, but the SDK is ready to extract conference URLs from any intent which
was registered as a conference activity.

This also opens the door for eventually adding Handoff support.

Share the code for extracting the URL for conference from a NSUserActivity.

WebRTC no longer actively fixes iOS 9 issues.

The upstream package has been unmaintained for 2 years now, and making the litle
changes needed as React Native needs them is getting old. The actual
funcionality is a couple of one-liners plus tons of boliterplate, which gets
reduced by quite a bit if we just embed it. So here it goes.

When a native iOS module implements `constantsToExport` it must define
`requiresMainQueueSetup`. In this case we don't do any UI stuff so it doesn't
need to be initialized in the main thread.

Make sure both methods offer the same behavior and mark the old one as
deprecated so SDK users get a warning.

There is no reason for them to run on the main thread, it's safe to call
AVFoundation functions on threads other than the main thread.

The previous code made an incorrect claim about the thread in which the audio
route change notification selector is called: it's called on a secondary thread:
https://developer.apple.com/documentation/avfoundation/avaudiosessionroutechangenotification

Fix the "mute ping pong" for once and for all. This patch takes a new approach
to the problem: it keeps track of the user generated CallKit transaction ations
and avoids calling the delegate method in those cases.

This results in a much cleaner and easier to understand handling of the flow: if
the delegate method is called it means the user tapped on the mute button. When
we sync the muted state in JS with CallKit the delegate method won't be called
at all, thus avoiding the ping-pong altogether.

In addition, make sure all CallKit methods run in the UI thread. CallKit will
call our delegate methods in the UI thread too, thsu there is no need to
synchronize access to the listener / pending action sets.

Fixes the following warning:

~~~
Module XXX requires main queue setup since it overrides `constantsToExport` but doesn't implement `requiresMainQueueSetup`. In a future release React Native will default to initializing all native modules on a background thread unless explicitly opted-out of.
~~~

For AppInfo and AuioMode, there is no need to initialize anything in the UI
thread, so just return NO.

Fixes: https://github.com/jitsi/jitsi-meet/issues/3086

This happend after initialization and joining a conference for the first time
in JitsiMeetView.

With this the RN component and the consumer app can share same CallKit
provider, configuration, and enable to be part of multiple listeners of
the CallKit flow events. The main driver of this is to enable the
consumer app to be able to report an incoming call to the OS before
loading the JitsiMeetView. Once the user answers the call, the app can
instantiate a JitsiMeetView, pass the CallKit call UUIID, and the Jitsi
Meet components will handle the connection and report back to CallKit
that the  call has been established.