streamsynchronizer: avoid pad release race during logging.

The pattern of

stream = gst_pad_get_element_private (pad); if (!stream) GST_WARNING_OBJECT (pad, "something went wrong");

can be dangerous if the pad's ref-count is not carefully managed. This is racey with gst_stream_synchronizer_release_stream, which outside of a CS calls gst_pad_set_element_private (pad, NULL) and gst_element_remove_pad (self, pad). The element_private check can be scheduled between these calls, and then the logging call can happen after pad destruction, resulting in a crash.

The safest thing seem to be to hold a reference here. The other dodgy looking use of this pattern in is gst_stream_synchronizer_wait, but that is called from a pad event function, which I think (?) is protected either by careful ref-counting, or pad locks. At least, I have not hit such a crash in my testing, but I have in the iterator case described here.