We require navigator.mediaDevices.enumerateDevices to exist.

This is only permitted when testing.testMode=true in config.js

- It can throw exceptions
- It doesn't return false on things which are not Number, just on things
  that are not NaN

Fixes: https://github.com/jitsi/lib-jitsi-meet/issues/2743

It doesn't get translated in the TS build, for one.

Script I used:

```python
import os

for (dirpath, dirnames, filenames) in os.walk('.'):
    if '.git' in dirpath:
        continue
    if 'node_modules' in dirpath:
        continue
    if 'dist' in dirpath:
        continue
    if 'types' in dirpath:
        continue
    for filename in filenames:
        path = os.path.join(dirpath, filename)
        if not path.endswith('.js') and not path.endswith('.ts'):
            continue
        #print(path)
        with open(path, 'r+') as f:
            #print(f)
            data = f.read()
            if '__filename' in data:
                p, ext = os.path.splitext(path)
                txt = f"'{p[2:]}'"
                print(txt)
                data = data.replace('__filename', txt)  # Assign the result back to data
                f.seek(0)
                f.write(data)
                f.truncate()
```

* feat(RTC) drop PERMISSION_PROMPT_IS_SHOWN event

It was never accurate since browsers have changed their behavior over
time and can be implemented in the application more reliably.

* squash: Update JitsiMeetJS.ts

* squash: Update hand-crafted JitsiMeetJS.d.ts

---------

Co-authored-by: Дамян Минков <damencho@jitsi.org>

This prevents the browser from starting the camera at 60 fps wherever supported as this could drastically affect the cpu and result in poor experience.

webrtc-adapter transforms "deviceId": "foo" to "deviceId": { ideal:
"foo"}.

This makes the camera non-selectable if the resolution constraints are
not met.

Setting the constraint to exact will sidestep that adapter behavior, and
express stronger intent.

Require cycle: lib/lib-jitsi-meet/modules/RTC/RTC.js -> lib/lib-jitsi-meet/modules/RTC/TraceablePeerConnection.js -> lib/lib-jitsi-meet/modules/RTC/RTC.js

If MediaStreamTrack.getSettings() doesn't return the height of the track, use the constraints passed to gUM for calculating the height. Fixes an issue for Firefox/Linux which could result in media not displayed.

* fix(events): unify events to a single EventManager type, add support for single typescript declaration

* fix(lint): fix lint

* fix(events): fix incorrect instatiation

* fix(events): clean up redundant methods

* fix(events): keep EventEmitter name, alias NodeEventEmitter

* fix(events): fix loose reference

* fix(EventEmitter): remove on/off alias as redundant

* fix(RTCUtils): bring event handlers under class to use same event emitter

* fix(RTCUtils): fix lint

It does no harm on RN, since it doesn't detect it as a supported browser
and bails out.

They have been deprecated and their valued can no longer be changed from
the default after M103.

Ref: https://groups.google.com/u/0/g/discuss-webrtc/c/2l7jWgreYpw?pli=1

With https://bugs.webkit.org/show_bug.cgi?id=179363 being fixed, we should now be able to switch between devices in call.

Provide a method for changing the capture fps for desktop tracks during the call. These changes to the lib are needed for making it configurable from the UI.

When the resolution option was being used, all the other constraints like frameRate and facing mode were being overwritten.

SDP utility classes are spread across RTC and XMPP directories now, moving these class files to a 'sdp' directory.

Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1571.

Disable simulcast for low fps screenshare and enable it for high fps screenshare. testing.capScreenshareBitrate config.js setting has now been deprecated.

* fix: high CPU on Chrome with low fps screen sharing

It turns out that if 5 fps is set on the track constraints,
Chrome will capture the original video in 30 fps and only
further down the pipeline will downsample it to 5 fps.
This results in very high CPU usage. Specify max FPS in
getDisplayMedia to fix the problem.

Getting rid of track.applyConstraints should also fix another
issue on Firefox where it reports 0x0 screen size after this call.

* ref(RTCUtils): remove trackOptions

* remove extra &&

Stop using the legacy pc constraints that are no longer wired up to WebRTC.

Apple added getUserMedia support for WkWebview based browsers like chrome and Firefox on iOS 14.3. These browsers behave as Safari does on iOS. Therefore, extend the Safari checks to these webkit based browsers as well.

RTCUtils.enumerateDevices was being called earlier than the RTCUtils.init which assigned that function

Fire PERMISSION_PROMPT_IS_SHOWN when none of the devices have a label
Fire a new SLOW_GET_USER_MEDIA event if the timeout for getUserMedia is exceeded

Update JitsiMeetJS.createLocalTracks to include the options for firing the above events
in the provided options argument. Deprecate the firePermissionPromptIsShownEvent flag in
method's signature

It has been `true` for a very long time.

Cleanup some unused code after the bump.

The old stream needs to be released while keeping the tracks intact