Be smarter about which hosts to send presence to when processing room joins

[anoadragon453]

Addresses #8956. Does not address "we should also only send presence updates when this is the first time a remote server shares a room with the local user". I'd like to tackle that in a separate PR as it will likely involve tracking which presence updates we've sent out in some form.

This PR attempts to eliminate unnecessary presence sending work when your local server joins a room, or when a remote server joins a room your server is participating in by processing state deltas in chunks rather than individually.

---

When your server joins a room for the first time, it requests the historical state as well. This chunk of new state is passed to the presence handler which, after filtering that state down to only membership joins, will send presence updates to homeservers for each join processed.

It turns out that we were being a bit naive and processing each event individually, and sending out presence updates for every one of those joins. Even if many different joins were users on the same server (hello IRC bridges), we'd send presence to that same homeserver for every remote user join we saw.

This PR attempts to deduplicate all of that by processing the entire batch of state deltas at once, instead of only doing each join individually. We process the joins and note down which servers need which presence:

• If it was a local user join, send that user's latest presence to all servers in the room
• If it was a remote user join, send the presence for all local users in the room to that homeserver

We deduplicate by inserting all of those pending updates into a dictionary of the form:

{
  server_name1: {presence_update1, ...},
  server_name2: {presence_update1, presence_update2, ...}
}

Only after building this dict do we then start sending out presence updates.

[anoadragon453]

@ShadowJonathan This PR is still a draft :P