This reverts commit 886bc1519d.

Turns out Chrome decides to not choose the maximum possible resolution when
given a range. Oh well!

Otherwise Chrome has been seen using a simulcast layer with a resolution of
240 x 135, which can break implementations not supporting odd resolutions, such
as WebRTC on Android.

Related Chrome issues:
* https://bugs.chromium.org/p/webrtc/issues/detail?id=6651
* https://bugs.chromium.org/p/webrtc/issues/detail?id=7206

PC constrain via configuration.

Lib-jitsi-meet uses Temasys on Internet Explorer and Safari so it does
not make sense to require its adapter.screenshare.js on React Native,
for example, where it fails anyway.

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.

Fixes resolving this when passing function after enabling es6.

Finds correct error when getUserMedia succeed with only one of the audio or video, and the other fails.

Fixes the availableDevices, to reflect the devices for which we succeeded or failed to obtain stream.

On Safari/IE we have to wait until the WebRTC stack is
initialized in case the plugin is being installed for
the first time.