Update notes:

- The base64-sha1 code got stripped out, so we bundle it now
- There are 2 optional dependencies which we want to ignore to avoid
  extra bundle size: xmldom and ws (the former is used by RN but we
  provide it in the app and the latter is only used by Node
  environments)

It's now in JitsiMeetJS.ts rather than .js.

Avoid needing an external dependency.

There is no need to treat js-utils differently, since it's now declared
as a module in package.json

Ref: https://github.com/jitsi/lib-jitsi-meet/pull/1957

* feat(multi-stream-support) Handle SDP munging for multiple local/remote streams/ep.
A new SDPSimulcast class is added for handling SDP munging for local and remote descriptions to handle multiple streams for both local and remote endpoints. This new class will be used only for unified plan implentation. The sdp-simucast npm package will be used for plan-b and deprecated later when all the clients switch to unified plan.

* fix(build) fix building with TS code

Use the Babel preset for the webpack bundle since Babel 7 already
understands TS and ts-loader uses tsc instead, which we configure
differently.

* squash: Add unit test and address review comments.

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

This is just the stepping stone towards the goal of eventually having
lib-jitsi-meet fully written in JS.

- introduce ts-loader for webpack
- webpack will continue generating the UMD bundle
- tsc will generate an ES6 module
- output all bundles to dist/

Improve compatibility with Webpack 5.

We are not actually using it here.

Adds a JitsiConference.getSsrcByTrack() method that finds the SSRC of a JitsiTrack by its SSRC. This method is currently used to get (and display) the first audio/video SSRC in the GSM popover in Jitsi Meet.

Co-authored-by: George Politis <gp@jitsi.org>

Avoid having to use a code blob.

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

The currently selected values are a bit above the actual sizes, so if a PR
increases the bundle size enough to trigger the failure, it should bump it.
It better have a good reason for it though!

Build as follows to build (production) bundle size stats:

npx webpack -p --progress --analyze-bundle

Then open the report:

npx webpack-bundle-analyzer stats.json

If we go beyond this limit, we'll have to put it on a diet.

js-utils has some, so we need the preset or webpack fails with a syntax error.

In order to include browser capabilities in RTCBrowserType I needed to
refactor RTCBrowserType.

ESLint 4.8.0 discovers a lot of error related to formatting. While I
tried to fix as many of them as possible, a portion of them actually go
against our coding style. In such a case, I've disabled the indent rule
which effectively leaves it as it was before ESLint 4.8.0.

Webpack 2 defines module.exports as a read-only property in ES6 modules.

The configuration of webpack 1 does not fully work on webpack 2 without
modifications.

Unfortunately, webpack 2 produces a larger jitsi-meet bundle at this
time. Since the webpack version of lib-jitsi-meet is restrained by the
webpack version of jitsi-meet, we cannot move to webpack 2 right now.

React Native's module bundler (aka packager) has its default Babel
preset - react-native/babel-preset - which it uses in the absence of a
custom .babelrc. Unfortunately, the default may be tripped by the
presence of a .babelrc in dependencies. Additionally, if the default
does not get tripped, the npm install of lib-jitsi-meet as a dependency
may fall into a recursion in which Babel attempts to transpile
react-native/babel-preset. To reduce the risks of stumbling upon such
problems, move Babel's configuration inside the Webpack configuration
file.

Using both include and test for a loader which is to process a single
file is more complex than necessary. Reduce that to a test only.

1. The minimized versions of the library lib-jitsi-meet i.e. the file
   lib-jitsi-meet.js with the default configurations of Browserify and
   Webpack are, respectively, 614KB and 424KB. That's a reduction in
   file size of approximately 30%. While such a reduction may be
   achieved with Browserify, such a configuration would be non-default
   i.e. it would be more complex.

2. The build process of the library lib-jitsi-meet with Browserify is
   split into three distinct steps by package.json: transpile, version,
   and minimize. The transpile step produces a .js file and a source map
   which get consumed by the minimize step (as input files). A possible
   problem appears during the version step which modifies the .js file
   without modifying the respective source map. Thus, there is a risk
   that the source map of the minimized version of the library
   lib-jitsi-meet is broken. The Webpack approach carries out the
   version step in a way that precludes the possible breaking of the
   source map.

3. The introduction of ES2015 forced us to split the Babel-related parts
   of the build process out of package.json into start_browserify.js. As
   may be seen by comparing start_browserify.js and webpack.config.js,
   there are similarities. The advantage of Webpack is that the other
   parts of the build process are inside webpack.config.js as well. In
   other words, there is no split in the build process and there is less
   complexity.