hash: openssl: check return values of SHA1_* functions

The function `ERR_error_string` can be invoked without providing a
buffer, in which case OpenSSL will simply return a string printed into a
static buffer. Obviously and as documented in ERR_error_string(3), this
is not thread-safe at all. As libgit2 is a library, though, it is easily
possible that other threads may be using OpenSSL at the same time, which
might lead to clobbered error strings.

Fix the issue by instead using a stack-allocated buffer. According to
the documentation, the caller has to provide a buffer of at least 256
bytes of size. While we do so, make sure that the buffer will never get
overflown by switching to `ERR_error_string_n` to specify the buffer's
size.

Per SSL_get_peer_certificate docs:
```
The reference count of the X509 object is incremented by one, so that it will not be destroyed when the session containing the peer certificate is freed. The X509 object must be explicitly freed using X509_free().
```

This makes it easier to cleanup allocated resources on exit.

Fixes #4440

While the OpenSSL library provides all means to work safely in a
multi-threaded application, we fail to do so correctly. Quoting from
crypto_lock(3):

    OpenSSL can safely be used in multi-threaded applications provided
    that at least two callback functions are set, locking_function and
    threadid_func.

We do in fact provide the means to set up the locking function via
`git_openssl_set_locking()`, where we initialize a set of locks by using
the POSIX threads API and set the correct callback function to lock and
unlock them.

But what we do not do is setting the `threadid_func` callback. This
function is being used to correctly locate thread-local data of the
OpenSSL library and should thus return per-thread identifiers. Digging
deeper into OpenSSL's documentation, the library does provide a fallback
in case that locking function is not provided by the user. On Windows
and BeOS we should be safe, as it simply "uses the system's default
thread identifying API". On other platforms though OpenSSL will fall
back to using the address of `errno`, assuming it is thread-local.

While this assumption holds true for glibc-based systems, POSIX in fact
does not specify whether it is thread-local or not. Quoting from
errno(3p):

    It is unspecified whether errno is a macro or an identifier declared
    with external linkage.

And in fact, with musl there is at least one libc implementation which
simply declares `errno` as a simple `int` without being thread-local. On
those systems, the fallback threadid function of OpenSSL will not be
thread-safe.

Fix this by setting up our own callback for this setting. As users of
libgit2 may want to set it themselves, we obviously cannot always set
that function on initialization. But as we already set up primitives for
threading in `git_openssl_set_locking()`, this function becomes the
obvious choice where to implement the additional setup.