Avoid fragile aliasing of SHA224/384 update/final

Avoid fragile aliasing of SHA224/384 update/final

This is purported to save a few cycles, but makes the code less
obvious and more brittle, and in fact breaks on platforms where for
ABI continuity reasons there is a SHA2 implementation in libc, and
so EVP needs to call those to avoid conflicts.

A sufficiently good optimizer could simply generate the same entry
points for:

        foo(...) { ... }
    and
        bar(...) { return foo(...); }

but, even without that, the different is negligible, with the
"winner" varying from run to run (openssl speed -evp sha384):

    Old:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k

    New:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k

Reviewed-by: Rich Salz <rsalz@openssl.org>