Expose SHA-256 functions

[jtraglia]

This PR exposes the blst sha256 functions in the auxiliary header. This is for c-kzg-4844 which currently patches blst to expose these functions. It would beneficial to us if these functions were exported. This PR only makes these functions available from C and not any of the other bindings. This is all we want/need at the moment.

[henridf]

A couple other repos that would benefit from this change are nim-blscurve (current workaround to expose sha256 at https://github.com/status-im/nim-blscurve/blob/master/blscurve/blst/blst_sha256.c) and the in-progress nim-kzg-4844 repo.

[dot-asm]

I don't see a compelling need for exposing the CTX structure. I mean why not instead of exposing init/update/final expose single-shot subroutine? One that simply takes data and emits its hash... With private CTX allocated on stack...

[dot-asm]

I mean

void blst_sha256(unsigned char md[32], const void *msg, size_t len)
{
    SHA256_CTX ctx;

    sha256_init(&ctx);
    sha256_update(&ctx, msg, len);
    sha256_final(md, &ctx);
}

for src/exports.c.

[jtraglia]

That's a good idea too. I like that approach. Will make the change.

[dot-asm]

Not that it actually matters in the context, but blst.h follows a specific convention for naming arguments that reflects so called typemaps in blst.swg. For this reason I'll change this line as I commit.

BTW, how would byte *msg look at your side? I mean void* is a convenient way to avoid specific type warnings [or rather excessive casts], but at the same type time it masks potentially meaningful programming mistakes. For example passing pointer to an integer might work in specific context, but formally speaking it's not exactly legit.

[jtraglia]

A byte *msg would be fine on our end. Our input is uint8_t* (byte*) so it works well.

[dot-asm]

Any hard objections, @henridf?

[henridf]

nope, I think this should work fine on my end too

[dot-asm]

Thanks!