One historical version of Themis has been using incorrect KDF which
produced data that cannot be decrypted with the correct function.
In order to work around this issue, the code contains a fallback path
which tries the incorrect compatibility KDF if decryption fails with
the derived key produced by the correct KDF.

Unfortunately, this code path is not tested whatsoever and this is not
good. Add tests that verify that Themis is able decrypt data produced
by buggy Themis 0.9.6.

P.S. clang-format surely has some weirdly twisted idea about how byte
arrays should be formatted *sigh* whatever...

Extract key derivation into functions like this is done for Seal and
Token Protect mode. This makes the code more readable and highlights
the compatibility issue that we are dealing with.

Update the usage sites too, remove magic macros, make sure that the
derived keys are wiped after processing.

It's really not obvious why Context Imprint's IV computatation is
performed with a key derivation function. At least extract this bit
into a separate function that can be commented.

Cleanup the usage sites, replace macros with plain C code, make sure
that IV is wiped after processing since it is derived from the key.

It has never been used since Context Imprint mode does not produce any
authentication token that needs a header.

It does not really make much sense for the users to not enable the
compatibility code path that allows to decrypt historical data.
In fact, not a single build that we distribute disables this code
path.

Remove all SCELL_COMPAT ifdefs and ignore NO_SCELL_COMPAT setting,
making the compatibility always enabled.

This has a side effect of slightly slowing down decryption of really
corrupted messages since we will be always trying the fallback path.
However, this is not that significant loss as originally envisioned,
and normal usage of Themis should not be affected.

First of all, 64-bit machines are more common so this code path will be
used in almost all cases. Second, 32-bit machines may need to deal with
data encrypted by Themis 0.9.6 on 64-bit machines, so disabling it for
32-bit machines does not make much sense.

This reverts commit 8a1781f.

Leave the compatibility code disable by default from now on. The
NO_SCELL_COMPAT configuration variable is now ignored. Instead,
WITH_SCELL_COMPAT=1 will enable the compatibility.

This compatibility code is going to be removed when Themis 0.9.6 finally
reaches end-of-life on 2020-12-13, so we are getting ready for it.

It happens to be used only by the compatibility code, so if it is
disabled then compiler starts spewing warnings about unused labels
and this makes our warning-free CI build unhappy. We will not need
this label with compatibility code removed so move it there.

Sync with master branch since some of git hackery in CocoaPods builds
seems to be not working well with branches. It should be okay when this
code is synchronized with master.