refactor: cleanup hash to better support multiple implementations

[lrstewart]

Release Summary:

Resolved issues:

related to #5257

Description of changes:

See #5257 for a high-level description of why I need to touch the hashing code.

Handling both hashes and raw input interchangeably requires a new hash implementation. However, our current hash code isn't organized in a way that makes it easy to get consistent behavior between implementations. Before I add the new implementation, I want to reorganize the existing code: the "s2n_hash_" methods should handle the fields shared between all implementations, and the specific "s2n_evp_hash_" methods should only handle the fields in the "digest" union that are specific to the EVP hashing implementation.

Testing:

There should be no behavior changes here, so existing tests should be sufficient. I'm just moving code around.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[lrstewart]

I'm convinced that this isn't currently true, and I'm not sure it was ever true? Wiping a connection doesn't erase the hash_impl-- and if it somehow did, it'd also likely somehow erase all the other state that hash_impl->free is supposed to cleanup and therefore cause a memory leak. hash_impl should be set on _new, when the implementation specific memory is allocated, and then never touched again.

The previous two hash_impls could be chosen between when s2n_init was called, so calling s2n_hash_set_impl repeatedly wasn't an issue. But if we're going to add more complex logic around choosing different hash_impls, then we need to be more clear about the s2n_hash_state lifecycle.