Add new and modify functions to support ZRTP protocol negotiation

To support more than one ZRTP protocol the application must add more than one
ZRTP hash attribute to SDP. Every supported version has its own ZRTP hello
hash.
Enhance SRTP statistic counters

Use different counters for the two different SRTP failures
Use the different counters for better SRTP problem reporting
Small fixes in packet counter handling
Implement new RS1/RS2 handling according to RFC6189bis

RFC6189bis requires new handling of RS1 and RS2, see section 4.6.1 of that
RFC.
Fix NULL pointer access

The stop functions may be called twice, thus check for null pointers.
Modify RS2 valid/invalid handling

RS2 is set to invlaid by default. Only if some problems occur during the first
few packt of the SRTP media data the client may set it to valid to enable ZRTP
cache synchronization/self-healing.
Merge branch 'newchache' into develop
Do not report ZRTP CRC errors on every occurance

According to RFC 6189 CRC erros should not raise a warning. Thus remove the
waring if we see only a few CRC erros. If we see more CRC errors during a ZRTP
negotiation we raise a warning.
Merge branch 'hotfixCrc'
Merge branch 'hotfixCrc' into develop
Implement a first ZRTP tunnel via SDES/SRTP

If both clients support SDES we setup and addiitonal SRTP crypto contexts with
different KDF parameters. We use these SRTP contexts to protect the ZRTP
packets.

This commit still has debug messages and uses a specific ZRTP magic handling
to be backward compliant.
Implement signaling interface functions to support ZRTP encapsulation

Remove the test and debug code and use the signaling functions to enable or
disable ZRTP encapsulation. The SIP/SDP stack uses these funtions to get or
set the relevant attributes.
Merge branch 'tunnel' into develop
Add SDES reset function

This method deletes the SDES context of a stream unconditionally.
Add counter and handling for RTP packet parse errors
Add a new getInfo key to get the security status
Modify timing when to set/reset ZRTP tunnel flag
Fix vulnerabilities found and reported by Mark Dowd

- limit length of memcpy
- limit number of offered algorithms in Hello packet
- length check in PING packet
- fix a small coding error
Add length sanity checks

The ZRTP code uses these sanity checks to see if a packet has given minumum
length. If this is not the case we report an error and stop further ZRTP
negotiation. The ZRTP code performs these sanity check before it applies the
real checks using the hash chain and the HMACs. The additional sanity checks
may avoid crashes in border cases:

If an attacker creates a really short packet (length of a HelloAck packet) but
it poses as a longer packet (Commit for example), and if the packet has a
memory start address that's near a read protected memory area then reading the
data to perform Hash/HMAC checks would access the protected area which could
lead to a crash.

These additional checks were proposed my Mark Dowd.