srtp: read Cryptex header extension from the input buffer on unprotect

srtp_cryptex_unprotect_init() read the RTP header-extension profile and
length from the rtp parameter, which on the unprotect path is the output
buffer. srtp_unprotect() documents that rtp "can be the same as srtp to
support in-place io", so a distinct output buffer is a supported calling
mode, and in that mode the output buffer has not been written yet when
this function runs -- the first write, memcpy(rtp, srtp, enc_start),
happens in the caller afterwards.

Cryptex detection and the enc_start adjustment were therefore derived
from whatever the caller's output buffer happened to contain rather than
from the packet that arrived. Two lines above the call site, the same
extension length is already read from srtp, so the two paths disagreed.

Read both fields from srtp instead. In-place callers are unaffected
because srtp == rtp there.

Add a regression test that unprotects a reference Cryptex packet into a
zeroed output buffer distinct from the input. The existing not-in-place
coverage copies the packet into a scratch input buffer and passes the
original packet buffer as the output, so the output buffer already holds
the ciphertext and the wrong-buffer read returns the right bytes by
accident; that is why this was not caught.

Without the fix the new test fails at offset 12 with c0 (the Cryptex
profile, still ciphertext) where be (the restored plaintext profile) is
expected. With the fix the full suite passes in both in-place and
not-in-place modes.