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.

The function filter_special_chars does not have to throw a TypeError
when its argument text is null or undefined because (1) it can be argued
that neither of these two contains special characters and (2) it is much
more convenient to have the check in the function in question rather at
its multiple call sites.