Feature a waiting room

### Your use case

#### What would you like to do?

I would like guests that want to join a call without any registered users in it to wait until there is someone there

#### Why would you like to do it?
I initially deployed Element Call for guests to join calls, and I have actively enforced rules for them to not abuse from it.

What I want to achieve is currently available with my specific setup (see next section), but the UX is horrible because I guess it was not really designed for this use-case

#### How would you like to achieve it?
I think the only thing to change here is the handling of the error message, and an automatic refresh at regular intervals.

### Have you considered any alternatives?

Currently, this behaviour is nearly accomplished by not deploying a LiveKit server for the guest matrix server: call creation coming from Element Call Standalone would fail, while joining a LiveKit call created by the registrered server would succeed.

The only problem here is this:

Instead of something like this:

### Additional context

It would be cool to officially support a setup without a LiveKit backend for the Element Call matrix server.

Currently, the only documentation fragment that helped me to go in the direction I took was in [Readme > Backend selection](https://github.com/element-hq/element-call#backend-selection):
> For the LiveKit MatrixRTC backend ([MSC4195](https://github.com/hughns/matrix-spec-proposals/blob/hughns/matrixrtc-livekit/proposals/4195-matrixrtc-livekit.md)), **the first participant who joined the call defines which backend will be used for this call** via the foci_preferred key in their org.matrix.msc3401.call.member state event.

And the self-hosting guide explicitly asks for a dedicated [LiveKit backend](https://github.com/element-hq/element-call/blob/main/docs/self_hosting.md#livekit-backend):
> In order to guarantee smooth operation of Element Call, a dedicated LiveKit backend is required for each site deployment.

Yet, doing the opposite actually gives a really cool security feature!

Start with the README's Backend selection section and docs/self_hosting.md, then trace the user-facing handling when guest call creation fails. Done means guests see a waiting-room state instead of the current error and are refreshed periodically until a registered participant is present.

Written by the indexing model from the issue text.