`createRoom` should be atomic

Currently createRoom can fail for various reasons, which will cause the homeserver to create a partial room. This confuses clients, since they will receive an error and no room id or they receive no error and a room id. While some of that is because of how servers implement it, there is at least one case which is unavoidable:

If you include multiple invites during room creation, some of those might fail because of the remote server rejecting the invite or simply being unavailable. This is not something that can be validated before creating the room, since the room id needs to be included in the invite. Additionally for multiple invites, the behaviour is not clear when the first invite succeeds and later invites fail.

There are a few ways this can be solved:

- Disallow invites completely on `createRoom`. This is probably not ideal for DMs.
- Disallow multiple invites/only allow a single invite. In that case the homeserver can verify that the invite succeeds and only then respond to `createRoom`.
- Have invites during `createRoom` require a multistep process, where the invite is announced to the remote homeserver first and only committed later.
- Allow returning success and a list of failed invites to the clients, which would not make the API atomic, but allow clients to know about the error.

Additionally it would be great if the spec was clear on if a room is created, when an error is returned or not.

Start with the createRoom specification and its handling of multiple invites, focusing on cases where a remote invite fails after room creation begins. Review the proposed alternatives and define one unambiguous outcome for room creation, including what clients receive when an error occurs and whether a room exists.

Written by the indexing model from the issue text.