WIP: Secure Transport support as OpenSSL alternative on macOS

As noted in 77FB2321-9210-4AD4-B7FC-67623A5838F0(at)justatheory(dot)com, OpenSSL is
being somewhat dismantled on macOS starting with 10.11 El Capitan. To scratch
my own itch I decided to take a stab at adding support for the Secure Transport
library. The idea is to make it as much of a drop-in for the OpenSSL support
as possible, supporting the same file formats etc (Secure Transport have PKCS12
API calls while support PEM requires using lower level APIs).

Only the frontend has been implemented so far. I used a vanilla OpenSSL-
compiled backend for testing (see patch 0002 below). Currently the CRL tests
fail since Secure Transport doesn’t handle manual CRL lists like OpenSSL, CRL
handling is done automatically by the Keychain upon validation. One
alternative for supporting this could perhaps be to create a temporary Keychain
for the duration of the connection over which more control can be had (need to
research this further). For now, no Secure Transport specifics are supported
but the idea is to add support for loading certificates and keys from the
Keychain as well as from the usual locations. The engine and compression
settings will however be no-ops since there is no support in Secure Transport
for these.

Being an early WIP show-and-tell submissions and not something up for code
review (anyone wanting to take a look is of course more than welcome), it is
deliberately rough around the edges. Except the manual CRL loading, it’s
mostly featurecomplete with the OpenSSL frontend, TODO items include: removing
use of private and deprecated API calls; ensure release of all resources;
support certificates/keys in Keychain; possibly use temporary keychains for
connections; support passphrase entering (there has been lots of deprecations
around that, need to figure out the supported way forward); tidy up, and write
better, comments; documentation.

The main questions raised here are: is it of interest to support multiple SSL
libraries given the additional support burden and; is supporting Secure
Transport of any interest or is it a wasted effort to continue towards a full
frontend/backend/doc submission?

On top of the OpenSSL situation in macOS, supporting Secure Transport makes
sense if the Keychain can be fully leveraged since that would allow IT
organisations to centrally manage and provision Mac clients without passing
certificate/key files around. Should there be any interest in this I intend to
continue on one more library which is more geared towards server environments
like nss or <suggestions-welcome> once Secure Transport is done (scratching
another itch).

The attached show-and-tell patches are:

0001. The WIP frontend support for Secure Transport together with minimal
scaffolding around it such as Makefile and autoconf.

0002. Adding support to PostgresNode.pm to run the server binaries from a
defined path making it easier to test a frontend without having to a)
implement the backend at the same time or b) fiddle with paths manually.
The SSL tests are the only ones modified. There is nothing Secure Transport
specific in this patch so iff the approach is deemed interesting it could be
considered out of band. Since the only consumer is testing SSL during
development it might be too invasive however.

0003. A first little stab at tweaking the docs to mention support for
multiple SSL libraries. There is a lot left here but the idea is to contain
the library specifics in subsections with the main sections being generic
SSL support information. On top of tweaking the existing sections I intend
(once done) to write up the steps needed to implement support for an SSL
library, this should perhaps be a README in the tree though?

Thoughts, comments?

cheers ./daniel