If the API client happened to try to add one and the same local video
track twice, the library would throw an error. I find that draconian
because:

1. The error message states that a second local video stream cannot be
added but that is incorrect because the API client is not trying to add
a second local video stream but add one and the same local video stream
multiple times.

2. The jsdoc says that a throw will happen if another local video stream
is added but that is misleading because the API client is not trying to
add another local video stream but add the same local video stream.

3. Adding one and the same local video stream multiple times can be
handled gracefully by the lib-jitsi-meet library. Thus, the library
appears more friendly.

Hence, gracefully handle the case of adding the same local video track
multiple times without throwing an error.

Fix non-ASCII letter in Statistics.sendActiveDeviceListEvent() method

via presence (via special items with a tag name beginning with
"jitsi_participant_). An events is fired when the value of a property changes.

You can call static Statistics methods which will internally handle callstats instances to send stats. Drops handlers and JitsiMeetJS references.

Logs versions of components and library version. Logs shard and region if available.

Since (1) half of the disco uses check whether the feature in question
is supported, (2) the other half appears to not absolutely require
disco, and (3) disco needs to be explicitly included/required in order
to be supported, make disco completely optional.

While we have JitsiMeetJS defined as a global variable in Jitsi Meet, it
doesn't sound like an absolutely necessary and beautiful requirement
inside the library itself.

Rename variables with "stream" in name which refer to JitsiTrack.
Rename TRACK ADDED/REMOVED events.
Try to reduce direct access to remoteTracks object.
Log warning message when track is overwritten.