sha256: support delegating to wolfSSL API

[vszakats]

Offered by wolfSSL v3.11.0+ (2017-05-04).

---

(Can be made work in v3.10.2 (2017-02-13) by including <wolfssl/wolfcrypt/types.h>, which looks like a wolfSSL early implementation issue.)

• figure out which wolfSSL version it requires. v3.10.2 (2017-02-13). Check for it, or bump minimum. → a higher version is already required without this patch.
• use the native wolfcrypt API instead? following lib/vtls/wolfssl.c? [FUTURE] → sha256, sha512_256: switch to wolfCrypt API #21090

[bagder]

Might as well bump the minimum version IMHO!

[vszakats]

According to tests, 5.0.0 is the current minimum required → PR #21080

[Copilot]

Pull request overview

This PR updates lib/sha256.c to delegate SHA-256 hashing to wolfSSL’s API when building with USE_WOLFSSL, aligning wolfSSL behavior more closely with the existing OpenSSL-backed implementation.

Changes:

• Add a wolfSSL-backed SHA-256 implementation path (via the OpenSSL-compat EVP interface) alongside the existing OpenSSL EVP path.
• Update the documented SSL-backend branch ordering to include USE_WOLFSSL.
• Split EVP context allocation / digest init-update-final between OpenSSL and wolfSSL APIs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new USE_WOLFSSL path unconditionally includes <wolfssl/openssl/evp.h> and calls wolfSSL_EVP_* APIs. wolfSSL’s OpenSSL-compat/EVP layer is not guaranteed to be enabled in all supported wolfSSL builds (e.g., builds without --enable-opensslextra), and curl’s configure currently only feature-detects a few OpenSSL-compat symbols (DES/BIO/etc). This risks build/link failures for otherwise-supported wolfSSL configurations.

Suggestion: add configure/CMake feature checks for the specific wolfSSL_EVP_* symbols used here (or a LIBWOLFSSL_VERSION_HEX guard), and fall back to the internal SHA-256 implementation when those symbols are unavailable (or switch to the native wolfCrypt SHA-256 API which is always present).

[Copilot]

In the OpenSSL/wolfSSL shared branch, the field name openssl_ctx is now misleading for the USE_WOLFSSL build where it actually holds a wolfSSL EVP context. Consider renaming it to something backend-neutral (e.g., evp_ctx/md_ctx) to avoid confusion when maintaining the dual-backend code.