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.

Our JSHint configuration is not extensive and we have excluded multiple
files from linting. Additionally, we have seen JSHint to be unable to
parse newer ECMAScript features such as the object spread operator
(proposal).

On the other hand, we have seen ESLint to beautifully work on React and
React Native source code in addition to ES2015 and later. Introduce
ESLint alongside JSHint as an intermediate step to eventually switching
from JSHint to ESLint.

As our source code does not fully follow even the JSHint rules we have,
it is very difficult to introduce ESLint with many rules. At the
beginning, introduce it with as little rules as possible. Morever,
ESLint is able to automatically fix certain rule offenders so once we
have ESLint merged we can incrementally add new rules while keeping our
commits' modification on as little subjects as possible.

The build process is capable of bundling both minimized and unminimized
artifacts for lib-jitsi-meet. However, there does not seem to be a good
reason to (1) always wait for the building of the two versions and (2)
distributing the unminimized artifact.

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.

This is in reference to the same type of issue on the jitsi-meet repo: https://github.com/jitsi/jitsi-meet/issues/694

output was produced. The pipe to exorcist hides failures
from the browserify itself.

Bumps the sdp-simulcast version to 0.1.7 that fixes issues related to SSRC
management.

Enables the library to be used via require. Example usage is a React
Native (mobile) app which bundles its dependencies (in its release
build).

Conflicts:
	package.json

Conflicts:
	package.json