Expose SHAKE-128 digest (SHA-3 family and SHAKE-256 are registered; SHAKE-128 is not)

[MarkAtwood]

Correction of the original report after checking master: SHA3-224/256/384/512 and SHAKE-256 are already registered in wp_wolfprov.c (present since v1.2.0, behind WP_HAVE_SHA3 / WP_HAVE_SHAKE_256). The remaining gap is SHAKE-128 only: no wp_shake_128_functions / name registration exists — SHAKE-128 appears only as a WC_HASH_TYPE_SHAKE128 case in wp_internal.c / wp_rsa_kmgmt.c (MGF1 mapping).

Why it matters: CPython's hashlib requires shake_128 among its guaranteed algorithms at interpreter startup. Under a wolfProvider-only OpenSSL configuration (default provider not activated — the fail-loud shape used in FIPS-style deployments), every Python process dies at startup on that one missing fetch, even though the rest of the SHA-2/SHA-3 family is served. One registration away from Python working under wolfprov-only configs.

wolfCrypt already implements it (wc_Shake128, WOLFSSL_SHAKE128); this is provider glue mirroring the existing SHAKE-256 registration.

Observed on: wolfProvider 1.2.0, OpenSSL 3.0.13 and 3.5, wolfSSL 5.9.1.
Repro: OPENSSL_CONF activating only libwolfprov + base, then python3 -c 'import hashlib' → aborts on the failed shake_128 fetch; openssl dgst -shake128 fails likewise (while -sha3-256 and -shake256 succeed).

[MarkAtwood]

Scope correction (title/body edited accordingly): the original report asked for the whole SHA-3/SHAKE family. On checking master, SHA3-224/256/384/512 and SHAKE-256 are already registered (wp_wolfprov.c, since v1.2.0). The remaining request is SHAKE-128 only — the one guaranteed algorithm CPython hashlib needs that isn't served. Apologies for the noise.