Fix "no data from source" before ICE has connected

I added reporting of Promise's reject reason in b10a1fc while merging
jitsi/ss_postinstall_fix since Promise's reject function has such an
argument. Hristo Terezov disagreed with it because reason is undefined
in the use case and found it to be confusing so I'm reverting to what he
intended in the first place.

We can not assume that the audio source is not sending any data based
on the stat until the media connection has not been established.

fix(SS): implement interval to check the status of the ext after install

Simplify the source code by using some ES6 features such as arrow
functions to avoid the use of 'var self = this', the shorthand for
method definitions in object initializers.

Fixes sip calling.

In case of roomPass is undefined, an error occurs: Cannot read property 'length' of undefined.

feat(feedback): Tries to send the detailed feedback to analytics

ESLint

Switch from Browserify to Webpack

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.

Do not access JitsiConference's eventEmitter, the functionality of
interest is publicly available through other methods.

Updates rtp stats to work with nwjs.

JitsiConference passed in the constructor and adding all events happen inside the feature.

As I see no hidden meaning in the current non-preservation of
alphabetical order, I prefer to facilitate scanning (in the fashion of
searching in a dictionary).

fix(SS): Temp fix for SS when the extension is not ready after 500ms after the install

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.

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.

Participant connection status tune up and extra logging

By default talk while muted detection is disabled.

Fires event only once when the user is muted, if he unmutes and then mutes back again a new event will be fired if local talking is detected.

Fires CONFERENCE_LEFT event once we receive our presence unavailable.

When we receive kick presence it is both 110 and 307 status code, so we were triggering both conference_left and kicked event. Now when we receive kick we process as it is 110 to clean participants and room and then fire the kick event.

When only one participant is in the room and leaves(hangups) the only participant in members is focus.

Extra logging

When ICE disconnects, reconnects or fails the events will be logged
on both Callstats and "analytics".

When 1 seconds was used it seemed to be overreactive.