Upcoming OpenSSL security levels disable "weak" crypto.

Bitrot:  OpenSSL 1.1.0-dev (aka the "master" branch) has new security
levels ranging from 0 to 5.

  * Level "0" is backwards compatible anything goes.

  * Level "1", the new default, is roughly 80-bit or greater security
    across the board (block ciphers, EDH parameters, EC curves, RSA
    bit lengths, ...).  It also disables anonymous ciphersuites,
    breaking "smtpd_tls_cert_file = none", and in is stronger than
    we want for opportunistic TLS.

  * The remaining levels are for now too strong even for mandatory
    authenticated TLS, they disable RC4, RSA keys shorter than 2048
    bits, and SSLv3.

Therefore, (subject to the presence of the feature detected via
macro recommended by Steve Henson), we revert the default security
level back to 0 in the application SSL context.  Users can if they
wish change this by appending ":@SECURITY=<n>" to the various tls
cipherlists.  TODO: we'll shold also add a main.cf parameter and
policy table overrides for this at some point, provided we can
figure out how to explain yet another "mumble_level" to the users.

When authentication is mandatory in either the SMTP client or in
the SMTP server (smtpd_tls_req_ccert = yes) we set the security
level to 1 to ensure adequately strong parameters.

When testing this, discovered that verification error reasons are
not logged in the SMTP server, cloned and tested corresponding code
from the client.

Sample logging (when client cert has wrong EKU):

    smtpd[63016]: certificate verification failed for localhost[127.0.0.1]: not designated for use as a client certificate
    smtpd[63016]: Untrusted TLS connection established from localhost[127.0.0.1]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    smtpd[63016]: NOQUEUE: abort: TLS from localhost[127.0.0.1]: Client certificate not trusted