Adding audio payload with unsupported clock-rate breaks pipeline

Adding an audio payload with unsupported clock-rate breaks the pipeline. For instance, GstOpusEnc supports rates { 48000, 24000, 16000, 12000, 8000 }.

``` c
owr_audio_payload_new(
OWR_CODEC_TYPE_OPUS,
100, // dynamic RTP payload type
44100, // clock rate
1 // channels
);
```

This code will create a broken pipeline, whose source-bin cannot link with the transport-agent. This becomes known late, and with a nondescript error message.

While I think implementing our own parameter checking for payloads, in addition to the Gst caps negotiation, would be wrong since it's duplication, but I think the errors could be friendlier.

Begin at owr_audio_payload_new and trace how an unsupported clock rate reaches the source-bin and transport-agent link. Reproduce the OPUS payload example with a 44100 Hz clock rate, then verify that the failure reports the unsupported rate clearly instead of producing a late, nondescript pipeline error.

Written by the indexing model from the issue text.