speech-dispatcher-dummy stream can not be monitored, stuck in PA_STREAM_CREATING state

### Steps to reproduce

Using Plasma Volume applet which has stream monitoring feature. The applet's VolumeMonitor object creates a pa_stream for monitoring peak volume levels of inputs and outputs. In case of "speech-dispatcher-dummy", the stream is stuck in PA_STREAM_CREATING state, and won't ever change states. We can not close a "CREATING" stream right away, and deferred closing via `pa_stream_set_state_callback` is useless because the state won't ever change. This causes a leak of one stream per switching to Applications tab in the applet.

### Obtained behavior

Dummy stream is stuck, it can not be closed, and eventually causes a leak in Plasma.

### Expected behavior

Definitely not this.

### Behavior information

Configuration files are basically untouched/default Arch Linux configs. espeak-ng module actually plays some audio via its own stream (tested with `spd-say` command), and it also suffers the same issue, but stuck/leaked streams are removed once the module starts synthesizing some speech.

### Distribution

Arch Linux

### Version of Speech-dispatcher

speech-dispatcher: 0.11.5-1
espeak-ng: 1.51.1-2

pipewire: 1:1.0.0-2
pipewire-pulse: 1:1.0.0-2
pulseaudio-qt: 1.3-1

### Additional information

Downstream bug report in Plasma (sort of, there seem to be multiple bugs behind it): https://bugs.kde.org/show_bug.cgi?id=477522

Closely related issue in pipewire: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2168

Start by reproducing the issue through the Plasma Volume applet's VolumeMonitor and inspect the pa_stream creation and state-callback behavior for the speech-dispatcher-dummy stream. Compare the behavior with the linked PipeWire issue and verify that the stream can leave PA_STREAM_CREATING and be closed without leaking when switching to the Applications tab.

Written by the indexing model from the issue text.