Consider switching from `AsyncSequence` to callbacks for state changes

[lawrence-forooghian]

Summary: remove or demote our use of AsyncSequence

Split from #232. So that when you receive a state callback, inside the callback you can be sure that the object that changed state is in the state that update tells you it changed to (you don't have this guarantee with AsyncSequence because the iteration is performed asynchronously). And for consistency I think that we should also do it for non-state things e.g. messages, reactions, typing.

The work here would be:

• change the subscription / event listening API to match that of JS (i.e. accept a listener, return a subscription object that has a method that allows you to unsubscribe) — at time of writing, the correct API to copy is that from Integration/single channel integration ably-chat-js#521
• test the currently-@specUntested spec points that refer to being able to unsubscribe
• update the SDK's internals to not use AsyncSequence
• update example app to use this new API
• update ably.com docs

I think we should also:

• consider whether we want to also offer an AsyncSequence API as a convenience (this is what Kotlin is doing with flows; see https://ably.atlassian.net/wiki/spaces/ENG/pages/3852795925/ADR-130+Adding+Flow+and+Jetpack+Compose+Support+to+Chat+SDK)
• decide which of these two APIs to use in the tests (I think that to figure this out you'll need to see whether the tests are a lot more unwieldy when you try and write them using listeners instead of AsyncSequence)

Notes:

• to avoid churn, I suggest basing this on top of [ECO-5253] Use a single channel for all features #247

┆Issue is synchronized with this Jira Task by Unito

[lawrence-forooghian]

We might be able to remove AsyncAlgorithms after this too.