Introduce MatrixRTCSession lower level group call primitive

[dbkr]

This adds a lot of code, but the intention here is to ultimately replace much of the code in GroupCall, which has a number of jobs including managing media and state events. This code manages only state events, so make things a bit more modular. It is also fairly extensively tested from the beginning.

• Adds a layer that is just about managing the events for a call, without any actual calling
• Switches to experimental new design for call members events, removing m.call events

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

Here's what your changelog entry will look like:

✨ Features

• Introduce MatrixRTCSession lower level group call primitive (#3663).

[daniel-abramov]

To not block the merge of the PR (as I understood you would prefer to merge it ASAP), I'll reply to the review request with a comment (GitHub allows replying with a comment, a request for changes or with an approve - I don't feel confident enough to approve it in a sense that there are some topics that IMHO should ideally be addressed before I can have a confidence that the code is sound, robust and does not exhibit any bugs). Some of the threads/questions have been addressed (thanks!), but I don't seem to have permissions to resolve conversations.

So far my primary concerns are the following:

1. I believe that this PR could have been split into separate ones: one for the widget API, one for the OIDC, another one for the LiveKit URL specific stuff (setting the URL etc?), and one (arguably the most important in this context) for the matrix rtc session. This would allow me to provide better examples when pointing out to issues (I have a feeling that some of the problems that I mentioned aren't viewed as "that big of an issue"; perhaps with better examples and more elaborate explanations I could have proven my point a bit better).
2. I'm not confident that we really need the rtc session manager at this point, I'd rather invested more on the rtc session itself. IMHO currently it's fairly complicated (for the amount of code that it contains it has a high accidental complexity) and feels somewhat brittle (my gut feeling is that there will be bugs and edge-cases with the changes introduced in the PR and the solutions for them won't be particularly elegant - e.g. the solution for the async/await function looks quite complicated atm and hard to understand and it's generally not a very idiomatic way of solving state access/synchronisation problems). I also think that the API surface of the matrix RTC session could resemble LiveKit's Room a bit more (conceptually it's the same thing and it would also help unifying/merging them once we work on a deeper integration to introduce cascading). I'm particularly picky on such topics because I think that the matrix RTC session is a foundation upon which the rest of the things are going to be built in the future. That being said, if the changes are considered temporary and we don't plan to build much stuff on top of that, it might be fine to leave it like this.
3. The things with getContent() and data types. I know that it's a general issue of the Matrix JS SDK and not specific to this particular PR, so I can't complain much, though I feel like we would need to address this problem rather sooner or later as it adds a lot of complexity to the code (it's not clear where the types are guaranteed to have the right datatype vs when they must be manually checked).

[dbkr]

I've created element-hq/element-call#1432 and element-hq/element-call#1433 to track your last two points (the first one obviously is just in relation to the size of the PR itself).