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.