Avoid OpenSSL functions are unconditionally called at OQS_destroy

[ueno]

When OQS_DLOPEN_OPENSSL is designated and low-level primitives are overridden with OQS_set_callbacks, OQS_destroy still indirectly calls EVP_free from OpenSSL. This adds a extra NULL check to avoid that.

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)

[baentsch]

This PR begs 1-2 questions in my mind: If the purpose is

to avoid OpenSSL functions being used when they are overridden with OQS_*_set_callbacks

then a) why did free_ossl_objects get called in the first place and/or b) why is EVP_MD_free not also replaced with an "alternative TLS lib" variant?

[ueno]

then a) why did free_ossl_objects get called in the first place and/or b) why is EVP_MD_free not also replaced with an "alternative TLS lib" variant?

Let me answer (b) first: the objects being freed here (i.e., fetched algorithm implementations) are exclusively used by the OpenSSL implementation, not used nor needed for alternative TLS lib variants.

For (a), to avoid calling free_ossl_objects entirely, liboqs needs to know which objects are used and which are not, as the current mechanism allows partial override (OpenSSL for SHA3 but GnuTLS for SHA2, ...).

[baentsch]

the current mechanism allows partial override

That's the explanation I've been looking for, Thanks @ueno .

[baentsch]

Conceptually LGTM, but a macro may make this more readable.

[SWilson4]

LGTM! Thanks @ueno.