Add AES_256_CM_HMAC_SHA1_80 and AES_256_CM_HMAC_SHA1_32 crypto

This changeset updates calls_srtp_parse_sdp_crypto_attribute() and calls_srtp_print_sdp_crypto_attribute() to assume there are skipped = or == padding characters when receiving/sending a=crypto … inline:… lines. This is mandated by RFC4568 SDPSecurity Descriptions for Media Streams - Section 6.1. SRTP Key Parameter:

When base64 decoding the key and salt, padding characters (i.e., one or two "=" at the end of the base64-encoded data) are discarded (see [RFC3548] for details).

My reading is that these = or == shall not be sent. When parsing a=crypto lines, the = or == shall be added, before passing the input to g_base64_decode(). Otherwise the latter cannot determine correctly the length of the decoded data.

I tested this with Linphone. The result is, that Linphone does only work properly, if the it receives the padding characters. So I told my SDP-mangler (rtpengine) to force inserting the ==/= padding characters (rtpengine strips them, when forwarding packets, unless the undocumented pad-crypto option is used). I filled https://github.com/BelledonneCommunications/linphone-android/issues/1851. When the padding characters are present, the encrypted connection is established using AES_256_CM_HMAC_SHA1_80 in both directions.