Swift has a longstanding bug where a framework and a type cannot be named the
same. We have somehow managed to not run into this, but it now seems to be
hitting us.

Since this is a breaking change, this starts the road for SDK 3.0.

Since we only support iOS 11, 32 bit architectures must not be built.

It was introduced in Xcode 9 and made the default in Xcode 10. We were forcing
the use of the legacy version, which doesn't support some new features that we
wish to enable, such as building the SDK for distribution.

It's available on both Xcode 10 and 11.

Based on work authored by Shuai Li <sli@atlassian.com>, Daniel Ornelas
<dornelas@atlassian.com>, and Lyubo Marinov <lmarinov@atlassian.com>.

1. Aligns the project structure of Jitsi Meet SDK for iOS with that for
   Android for better comprehension.

2. The command `react-native run-ios` uses the last Xcode project or
   workspace in the list of these sorted in alphabetical order. Which
   limits our freedom in naming. Thus having only an Xcode project in
   the root directory of the iOS project structure gives us back the
   freedom in naming.

3. Allows the Podspec to work for the app project in addition to the sdk
   project because we need Crashlytics in the app which is integrated
   via Cocoapods as well.

4. Further removes references to JitsiKit in the source code for the
   sake of consistent naming.

Ladies and gentlemen, allow me to introduce you to Jitsi Meet SDK for iOS, the
mobile SDK which powers Jitsi Meet.

The goal is to encapsulate the entire React Native app into a framework / SDK
and offer an API for native (ObjC or Swift) applications to embed the Jitsi
conferencing experience.

While React Native can be embedded in native applications, I don't think it was
designed to be embedded as part of a framework, 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:

- Universal / deep linking needed to be wrapped to avoid the embedding app from
  linking with RN.
- The bundle URL had to be manually constructed, since RN considers that all
  resources are in the main bundle, but in case of a framework that is not the
  case.
- Custom fonts had to be manually loaded, since UIAppFonts doesn't work on the
  framework's Info.plist file.
- The RN packager has to be manually triggered since the React project will no
  longer do it for us.
- Custom App Transport Security rules were added since the builtin way to do it
  modifies the framework's Info.plist, which is useless in this case.

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

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.