Add RTCP support to RTP forwarders

[lminiero]

This patch complements the RTCP support added to the Streaming plugin in #1279, and can actually be used whenever there's need for RTCP feedback for RTP forwarders (even though their usage with the Streaming plugin is the main use case that motivated us here).

It's quite easy to use. Whenever you create an RTP forward, you can specify audio_rtcp_port and video_rtcp_port as well, e.g.:

sfutest.send({
	message: {
		request: "rtp_forward",
		room: 1234,
		publisher_id: myid,
		secret: "adminpwd",
		host: "192.168.1.80",
		audio_port: 5002,
		audio_rtcp_port: 5003,
		video_port: 5004,
		video_rtcp_port: 5005
	}, success: function(result) {
		console.log("Audio forwarder:", result["rtp_stream"]["audio_stream_id"]);
		console.log("Video forwarder:", result["rtp_stream"]["video_stream_id"]);
	}
});

This configures the remote RTCP ports, just as you configure the remote RTP ports with audio_port and video_port. This results in the plugin creating a new socket, binding to a random port, and latching to the remote specified port(s) in order to be able to receive RTCP feedback. This means that, after the forwarder did its latching, it's up to the recipient to figure out the port the forwarder will wait RTCP feedback on, exactly as the Streaming plugin currently does.

At the moment, we ignore everything that isn't a PLI/FIR, which means configuring an audio RTCP port is pretty useless. In future commits we can extend this for other RTCP packets: anyway, this already allows me to configure an RTCP port for a Streaming mountpoint, configure a new RTP forwarder to send RTP there and latch to the RTCP port, and make sure that any time a new Streaming plugin viewer opens the mountpoint their keyframe requests are properly relayed to the original source (the VideoRoom publisher).

Tested briefly and it seems to work, so I plan to merge soon. Feedback welcome!

[lminiero]

Merging.