Allow socket sharing between repair RTP and primary RTCP

If the primary stream RTCP feedback target port number has been
set to the RTP port number of the repair stream the same socket
(and thus same src and dest ports) will be used for both.  This
allows NATs to be traversed without requiring STUN or other
complex NAT traversal mechanisms.

This means that any RTCP replies from the server will be
multiplexed with the repair RTP stream.  Currently VQE-C will
ignore (drop) any of these RTCP packets but demuxing could be
added in the future.  This is consistent with RFC 6284 - "Port
Mapping between Unicast and Multicast RTP Sessions".
Demultiplex RTP and RTCP messages if they are set up to arrive on same port

If the primary stream RTCP feedback target port number has been
set to the RTP port number of the repair stream the same socket
(and thus same src and dest ports) will be used for both.  This
allows NATs to be traversed without requiring STUN or other
complex NAT traversal mechanisms.

A previous commit added support for this configuration without
demuxing where RTCP messages would just be dropped.  This commit
adds the actual demultiplexing such that VQE-C will internally
route the RTCP messages to the appropriate bits of code.
Prevent VQEC from running out of memory

It seems there's a  bug in VQEC  that manifests itself with a fact
that it's running out of memory  surfacing VQEC_ERR_SYSCALL error.
This happens  despite the fact that the number of active tuners is
actually lower then the maximum specified in the config file.

This commit fixes that problem by using malloc/free instead of the
custom allocators normally used. VQEC  allocates all of its memory
upfront,    trying   to   prevent, bad malloc/free implementations
memory  fragmentation, spikes, performance  related   issues,  and
abstract memory allocation  for  th e case when VQEC is running in
the kernel. Sadly this mechanisms fails in our case when it really
should not.

Since in our case we're running on relatively powerfull  box, with
lots of memory, using malloc/free should not harm us.

It's worth to mention that possiblility of running VQEC in kernel
mode seems to be an unnecessary complication in the year of 2013.
Ideally we'd like  to  see this  feature  go for the sake of code
simplificaton.
Allocate a random receive port when in sig_mode=std as well as sig_mode=nat

The SDP file is used to communicate what ports the server is using to
the client such that the client can use these ports as destination port
for RTCP messages and local port for connecting to multicast groups.
The SDP file cannot specify which ports the client should use as it
can't know which ports are available and the ports will be changed when
traversing NAT anyway.

For some reason, when sig_mode="std" is set and the primary stream is
a multicast stream the server ports are mirrored in the client.  This is
dangerous as the specified ports may already be in use by some other
process in the system and failure is guaranteed if multiple channels
(e.g. multiple SDP files) specify that the same server port should be
used and more than one of these channels is tuned at any one time.

This commit removes the conditional such that sig_mode="std" behaves the
same as sig_mode="nat" and the client ports are allocated as needed by
the kernel avoiding these issues.  This should be a obviously correct
change but it involves removing two conditionals which seem to have been
very deliberately included.  Unfortunately the comment that used to be
there only describes what the conditionals do rather than why they exist
at all.

This should have no effect for clients configured with sig_mode="nat".