feat: add an topic event enumerable

[malandis]

Introduces an interface ITopicEvent which covers both normal
messages (TopicMessage) and system events (TopicSystemEvent). We
refactor the internals of the stream to be over ITopicEvents, so
that we can filter to just TopicMessage (as is implemented
currently) or pass through all events in an event enumerable.

To enumerate over all events in the stream, call GetAllEventsAsyncEnumerable,
or WithCancellationForAllEvents.

This largely parallels the existing enumerator over messages only. See the
integration tests for an example usage.

[malandis]

Opening for early review for opinions on naming and organization. Currently the subscription response object has a GetAsyncEnumerable method which allows users to consume TopicMessage instances -- text, binary, or error. We will add a new method GetEventAsyncEnumerable which will allow users to consume TopicMessage as well as heartbeats and discontinuities.

To organize this we've introduced an interface ITopicEvent which both TopicMessage and TopicSystemEvent will implement. The latter covers the system events heartbeat and discontinuity.

[nand4011]

'event' feels like 'a thing that happened' to me. I like it for TopicSystemEvent, but I'm not as sure about ITopicEvent also representing normal messages. Maybe ITopicItem? I don't have too strong an opinion on it though.
The same thing with GetEventAsyncEnumerable. By the name alone I would assume it would be for exclusively system events, but the docs would clear that up. GetUnabridgedAsyncEnumerable could work, but might be too much of a mouthful.

[cprice404]

'event' feels like 'a thing that happened' to me. I like it for TopicSystemEvent, but I'm not as sure about ITopicEvent also representing normal messages. Maybe ITopicItem? I don't have too strong an opinion on it though. The same thing with GetEventAsyncEnumerable. By the name alone I would assume it would be for exclusively system events, but the docs would clear that up. GetUnabridgedAsyncEnumerable could work, but might be too much of a mouthful.

There was a thread in slack when we did this work for golang, and Event is the name that most people settled on, so as far as the public API for this goes I think we should be trying to mirror (semantically) what we did in go. I think it probably makes sense for the parent type / interface to include the word Event even though I do agree there is a bit of ambiguity for normal messages.

[cprice404]

i think i'm good with the names so far.

might be good to get @anitarua to weigh in since she did the prev two.

[anitarua]

Yeah, I think the names are fine here, ITopicEvent implemented by TopicMessage and TopicSystemEvent.

In the Go SDK, TopicEvent was implemented by TopicItem (string or byte messages), TopicHeartbeat, and TopicDiscontinuity.

[malandis]

Given the consensus, I've left the names as is. As Anita pointed out, there's a difference in naming vs the Golang SDK.

In the protos we have SubscriptionItem and TopicItem. SubscriptionItem now matches ITopicEvent and covers text, binary, heartbeat, and discontinuities. TopicItem in the protos has been called TopicMessage in .NET. We'll leave the latter as is for backwards compatibility.