Handle digest initialization failure when hashing

[djbclark]

Three functions in this file called EVP_DigestInit() or
EVP_DigestInit_ex() without handling failure, each in a different way:

• HashFile() and HashPubKey() zero their output digest and fill it in
  only on success, so on failure the caller received an all-zero
  digest indistinguishable from a real one. Both return void, so the
  digest buffer alone carried no success indication, and neither
  logged anything.
• HashNew() ignored the return value entirely and then called
  EVP_DigestUpdate() and EVP_DigestFinal_ex() on an uninitialized
  context, returning a non-NULL Hash whose digest is meaningless.

Each has a sibling in this same file that already does the right thing,
which is what the fixes are modelled on: HashString() logs in exactly
this case, and HashNewFromDescriptor() logs, destroys the context and
returns NULL. The asymmetry dates from the commit that first moved
these functions into libntech and looks like an oversight rather than a
decision.

HashFile() and HashPubKey() now log an error. HashNew() now logs and
returns NULL, matching HashNewFromDescriptor(); its callers already
handle NULL, which it returns on four other paths. HashBasicInit() moved
below the check so the failure path has nothing to free.

The failure is reachable in practice, not just in theory. On OpenSSL 3,
CryptoDeInitialize() unloads the default provider and every subsequent
EVP_DigestInit() fails; anything hashing after that point was silently
affected. That is how this was found. HashPubKey() is the most serious
of the three, since a public key digest that silently becomes a constant
is an identity that collides across hosts, and it feeds lastseen and the
TLS paths.

Verified by exercising each function before and after
CryptoDeInitialize(). Before this change the second call returned an
all-zero digest from HashFile() and HashPubKey() and a non-NULL Hash
from HashNew(), all three logging nothing; after it, HashFile() and
HashPubKey() log an error and HashNew() returns NULL.

Making failure detectable by the callers of HashFile() and HashPubKey()
rather than merely visible in the log would mean changing the return
types of two void functions with callers across both repositories, and
is deliberately left out of this change.

No unit test: forcing EVP_DigestInit() to fail requires deinitializing
the crypto library, which lives in cfengine/core's libpromises and is
not available to libntech's own tests.

---

This PR is against the fork, not upstream. It exists to give the change a
stable review URL and diff while the upstream ticket and PR are prepared.
The upstream target is NorthernTechHQ/libntech.

Base is the fork's master, which is identical to upstream master
0c0620d6c5f8f8d1cae212f084b021cff0b86ce6 — this branch is 1 ahead, 0 behind.

Verification: 6 real EVP_DigestInit* call sites in libntech, all in
libutils/hash.c; 3 were unguarded, now 0 of 6. Builds clean; hash_test
passes (6 tests). 21 insertions, 3 deletions, one file.

[djbclark]

Now tracked upstream in Jira as CFE-4717, alongside the upstream PR NorthernTechHQ#291.