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.