* feat: use getSynchronizationSources on the receiver for remote audio levels
Use getSynchronizationSources if it is supported, fallback to using getStats otherwise.
* feat/ref: Use the local audio levels from LocalStatsCollector
When using getSynchronizationSources, use the audio levels from LocalStatsCollector for NoAudioSignalDetection.js
Remove obsolete code - TalkMutedDetection feature using audio levels is not used anymore

This has become obsolete thanks to ES6 arrow functions

In order to include browser capabilities in RTCBrowserType I needed to
refactor RTCBrowserType.

Webpack 2 defines module.exports as a read-only property in ES6 modules.

For audio previewing, some browsers cannot have multiple local
audio streams at once. For audio output previewing, local
stats need to be collected to detect changes in volume level.

Pull Request #435

LocalStatsCollector uses a global AudioContext for implementing metrics on webrtc audio streams. If there is an audio stream the stream gets attached to the global AudioContext and metrics for this stream are collected.
When using lib-jitsi-meet with no audio streams (for example only screen sharing) the orphan AudioContext does have a default audio level. In other words even if no audio stream is attached to it the element plays some default sound using cpu/battery and most crucial in clients with virtualized harware causing network traffic to send audio output to local hardware which clients are operating.
The solution provided suspends the global AudioContext right after its creation. Therefore, there is no default audio signal emitted by it.

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.

module.