Workarounds for missing curves in OpenSSL

In case where the OpenSSL version used cannot successfully do openssl s_client
connects there are a few problems, see #1087.

This PR partly addresses them by
* changing the logic of HTTP header failure: we don't terminate anymore but
  continue with a warning message
* we try to find out what the reason was: If it is a missing curve we signal
  it back to the user
* we keep track in a global variable KNOWN_OSSL_PROB. It's not being used yet
  on all connects as it has not been decided whether we do a connect despite
  we know if there's a problem or rather not.
* Give hints to the user for resumption tests, secure renegotiation, CRIME and BREACH.
  For the latter --assume-http needs to be supplied for any output.

Also: for finding the OPTIMAL_PROTO now (unless --ssl-native is being used)
sockets are the default which removes in cases where an openssl s_client
connect fails, the initial message 'doesn't seem to be a TLS/SSL enabled server'
and prompt 'Really proceed ? ("yes" to continue)'. For STARTTLS this needs
to be done as well.

Here a minor bug was fixed: when openssl s_client connect in determine_optimal_proto()
succeeded without a protocol supplied, OPTIMAL_PROTO wasn't set. A statement was
added but now it is only being used when --ssl-native was supplied.

Leftover for this workaround is to find out why the number of certificate retrieved is
zero in those cases, despite the fact that there's a valid 'host_certificate.pem' from
tls_socket() calls.  Thus still run_server_defaults() stops after 'TLS clock skew'
as certificate_info() is not being called in run_server_defaults(). For now in
those cases 'Problem: Host certificate found but we can't continue with "server defaults"'
is being printed.

In general for the future it would be great if we could e.g. retrieve the header over
TLS sockets.