Prevent error on systems with older cURL compile target

[spackmat]

On systems, where the PHP cURL extension is compiled against an older version of cURL without support for public key pinning (e.g. the builds from https://rpms.remirepo.net/ for RHEL/CentOS 7), the CurlHttpDriver fails with a 500 error, stating that the constant CURLOPT_PINNEDPUBLICKEY is not found. For the worse this happens even when the PHP installation itself uses a newer cURL, but the extension doesn't know about that constant and its corresponding cURL option.

This PR adds a feature test to omit the certificate pinning on systems that don't support it (i.e. where the constant is not defined), otherwise the whole Threema-API cannot be used at all on those systems.

[spackmat]

The error message is, for those who search for it:

Undefined constant "Threema\MsgApi\HttpDriver\CURLOPT_PINNEDPUBLICKEY"

At first, I thought using \CURLOPT_PINNEDPUBLICKEY instead of CURLOPT_PINNEDPUBLICKEY would solve the issue, but that is not the case. The problem is that my hosting (uberspace U7) is based on CentOS 7 and the cURL extension is compiled against its originally shipped cURL 7.29.0, while that public key pinning is available from cURL 7.39 on. So the extension doesn't know about public key pinning, regardless of the currently used cURL version of that PHP installation, which is 7.76.1 (you can use php -i | grep 'cURL Information' to check that).

To make it short: Unfortunately we cannot assume CURLOPT_PINNEDPUBLICKEY as available, even if we declare PHP >= 7.2. In my case it is PHP 8.0. Oh, how I'm in love with such unforeseeable deploy-time (hopefully staging-time) problems…

[pavarnos]

Thanks