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.