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.

Since React Native doesn't have HTML elements, depend on HTML element
properties and don't necessarily depend on them being properties on
actual HTML elements but rather assume plain JavaScript objects.

The react-native-webrtc implementation that we use on React Native (at
the time of this writing) provides a MediaStream (class) which:

- has no standard constructors but rather has a non-standard
constructor which requires a single argument that represents the id of
the MediaStream instance to initialize, and

- has an id value of type number rather than the standard string.

Depending on the type of browser within which the library is executing,
we take the decision how many times to call getUserMedia (e.g. once for
audio and once for video on Firefox). Upon getting a result of the
call, we used to perform similar browser type checks. I see this as
repetition of logic which makes it difficult to add new browser types
(e.g. React Native). Try to examine the result of the call to
getUserMedia and thus avoid re-checkign the browser type.