Make event queueing explicit

The SSF spec talks a lot about the moment that a Transmitter sends an event to a Receiver. However, that is not the only moment in the lifecycle of an event. An event's life goes through the following steps (wrt to SSF):

1. An event happens and is reported to the Transmitter
2. The Transmitter queues the event on zero or more streams
3. The Transmitter sends the event to the Receiver OR the Receiver polls the event from the Transmitter

The spec should make these steps more explicit because it will help to make sense of the stream status information. For instance, when a stream is enabled, all three of these steps happen. When a stream is paused it means that 1 and 2 still happen, but 3 is temporarily stopped. When a stream is disabled, only 1 happens - both 2 and 3 are ignored.

By connecting the stream status to these event creation and queueing moments, it will become easier to answer questions like, "What should happen to polling streams when the stream is paused?"

Start by locating the SSF specification sections describing event sending, polling, and stream status. Trace the lifecycle steps against enabled, paused, and disabled streams, then update the specification so queueing and delivery behavior are explicit, including the open question about polling while paused.