Switch from using Marcin's OpenSSL [1] to our own build of OpenSSL [2]
which provides newer OpenSSL 1.1.1g, bitcode, and other goodies.

[1]: https://github.com/krzyzanowskim/OpenSSL
[2]: https://github.com/cossacklabs/openssl-apple

The new OpenSSL is distributed as a binary-only framework. It will be
downloaded from GitHub instead of building it from source. This is not
much different from what the previous vendor did, but is more stable.

Carthage builds use the static flavor of the framework.  We have run
into issues with dynamic framworks of OpenSSL when using Carthage, but
static frameworks seems to do very good job: the resulting binaries are
smaller, apps start a bit faster, and users are freed from the hassle of
dealing with OpenSSL linkage to their app.

Note that due to the way static linkage works, we will be exporting all
OpenSSL symbols from ObjCThemis by default. In order to avoid conflicts,
export only limited subset of symbols: Objective-C classes of ObjCThemis.

Switch from using Levi Groker's OpenSSL [1] to our own build [2] which
provides newer OpenSSL 1.1.1g, bitcode, and other goodies.

[1]: https://github.com/levigroker/GRKOpenSSLFramework
[2]: https://github.com/cossacklabs/openssl-apple

The new OpenSSL is distributed as a tricky pod, but for consumers like
Themis it's just a pod.

Introduce a separate subspec for the build with newer OpenSSL, and make
it the default choice. We keep the old specs around in case someone
needs them to share GRKOpenSSL or BoringSSL with other dependencies,
as it is not possible to use CLOpenSSL simultaneously with them due to
OpenSSL symbol conflicts.

The new subspec has its oddities, but it's all (un)known magic that
seems to be absolutely necessary to build Themis properly for iOS.

In Carthage builds, we need to export not only Objective-C classes
from TS namespace but global functions as well. (Well, there is only
one such function right now: TSGenerateSymmetricKey().)

It seems that Xcode 10 cannot handle bitcode data embedded into prebuilt
OpenSSL frameworks we distribute which were built with Xcode 11.2. Make
Xcode new minimum requirement for ObjCThemis and SwiftThemis. Xcode 11.0
is known to work.

Turns out that the spell we used before is not effective. sed does not
understand "\s" so replace it with "[ ]" to match the leading spaces.
Now the podspec should be correctly edited for linting and validate
as if the current commit is going to be published. (The hack will be
disabled for production branches where we are linting the spec as is.)

Make sure that ObjCThemis is compiled for arm64e architecture as noted
in Apple guidance [1]. This is important for the case when our users
would like to test teeir apps with this architecture. Currently, Xcode
does not build slices for this architecture by default, so Carthage
builds will not include it.

[1]: https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication

It seems that in some cases bitcode gets disabled in Xcode. Make sure
that our project files keep it enabled at all times.

It seems that ObjCThemis does not support arm64e very well, after all.
Let's not mention it in the changelog. Maybe the situation will impove
before 0.14 is out though.