PBSR-92: Separate conference implementation from the switchboard service

This is just the separation of Jitsi and general support for conference solutions without the switchboard capability. Support for different presence providers is not implemented here. Zoom is also still bound to the switchboard.

Jitsi and the generic "email" and "invite" actions are enabled as soon as io.ox/switchboard/standalone/extensions.js is loaded. This happens now with either the existing switchboard or the new jitsi capability. This loads the new io.ox/switchboard/jitsi.js module, and through that, the standalone extensions. To actually have Jitsi, the settings io.ox/switchboard//jitsi/enabled and io.ox.switchboard//jitsi/host still need to be also set, like before.

The Switchboard API was split into two:

• io.ox/switchboard/standalone/api can be used without the switchboard service.
• io.ox/switchboard/api extends the standalone API object with the switchboard-specific elements, so that it becomes identical to the previously available API.

A conference solution which works both with and without the switchboard only needs to require the standalone API, and if the switchboard capability is set, it can use the full API on the same object. (See io.ox/switchboard/jitsi.js for an example.)

The function createJitsiMeeting is still in the generic API object. Theoretically, a separate module with just that method would need to be created as "the Jitsi API", but it has no functional impact so far. In the end, after Zoom is split out too, to be able to verify that the implementation is truly generic, the strings 'zoom' and 'jitsi' should not appear anywhere outside of the implementations of the respective conference solutions. So for that, createJitsiMeeting should still be moved somewhere else in the end.

The extensions module was split pretty much the same way as the API. The standalone version now provides common code as an API for the other module and for the Jitsi implementation. Since it now can be loaded as a dependency, the old check for smartphones has to be performed at runtime and conference solutions need to check whether the module returned an API object or undefined.

With the full implementation of PBSR-92, there will be many more combinations than just the 2 we have now (with and without switchboard). Having different API modules for each might not be feasible, so some other type of feature detection might need to be used. Preferably one that the conference solutions don't need to explicitly check. Extension points like io.ox/calendar/conference-solutions actually already work that way (e.g. in the new Jitsi implementation), so that approach seems ideal. Then we could also get rid of the split APIs again.

For easy branding, all user-visible names should also go through extension points, like the existing label and the new joinLabel in io.ox/calendar/conference-solutions.