Revamp the `SyncUntil` API

[kegsay]

There's now a good number of use cases for a better version of SyncUntil and friends. As of #267 we now have:

• SyncUntilTimelineHas
• SyncUntilGlobalAccountDataHas
• SyncUntilInvitedTo

which all call SyncUntil with varying parameters. Using functional options here (like client.MustDoFunc) seems like the obvious solution. This also allows both timeline/account data to be checked in a single go, etc. By doing this, we can also adjust the thing we are looping over (obviating the need for things like #245 and #246).

In terms of since token handling (e.g #247), it's a lot clearer in tests if the token is returned to the caller rather than side-effected on the client. Consider:

alice := deployment.Client("alice", "hs1")
postInviteToken := alice.SyncUntil(...get invited)
alice.JoinRoom(...)
postJoinToken := alice.SyncUntil(postInviteToken, ...get join)

This gives flexibility to start from an initial sync or do an incremental sync.

[ShadowJonathan]

Could we maybe make an API that'd accept OR and AND boolean operators?

Something like;

Sync Until...
  AND:
    OR;
      Has Joined Room: X
      Has Joined Room: Y
    Time Line Event: Z

Which'd be represented with;

alice.SyncUntil(t,
  sync.And(
    sync.Or(
      sync.HasJoinedRoom(X),
      sync.HasJoinedRoom(Y),
    ),
    sync.TimeLineEvent(Z),
  )
)

---

IMO there should also be "bail" variants, i.e. "bail if we see condition A, B, or C" (which themselves can be constructs of above as well, i.e. alice.SyncUntil(t, sync.HasJoined(X), sync.Bail(sync.HasBeenBannedFrom(Z))

These could just become timeout bailing, but bailing can possibly provide better readability of "this should not happen", and signal to homeserver devs that such a condition is a definite invariant failure.

[kegsay]

I'm explicitly omitting control flow logic like this because it's nearly always less clear than just writing custom check functions which do the same thing but with actual Go code as control flow rather than nested functions.