use and correctly handle PadProbeReturn.REMOVE

[MaZderMind]

When GSTPAD_API.gst_pad_add_probe is called with a mask of IDLE which usually is what we want when calling block(), it can, if the pad is already IDLE directly call the probe-callback from the calling thread.

In the case of block() this will directly jump into the Pads eventReceived method, which will directly call removeCallback.

removeCallback tries to find the callback-object in the Pad's signals but fails to do so, because we actually have not yet created the actual callback object - we're still stuck in the constructor-call of the GCallback object.

Actually the GCallback is registered only after the actual callback has been executed for the first time, and it will be called again – and only on the second invocation it will actually be removed. Often, especially when unlinking the pad in the block-callback, there might not be a second invocation and the probe might be dangling forever.

The solution to this is to return PadProbeReturn.REMOVE from the block-callback. This will cause GSTPAD_API.gst_pad_add_probe to return a probe-id of 0, which can be used in addEventProbe to detect that the requested probe has already been handled and there is no need for it to be registered on the GObject. I implemented this optimization in this PR.

This fix is part of a set of fixes for #184 and is extracted from #186

[neilcsmith-net]

Thanks, looks good.