src/common/pqclean_shims/compat.h: Fix polyfill version check sense

[distorted-mdw]

We need to define the types if GCC is too /old/.

• 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 oqs-provider, OQS-OpenSSL, OQS-BoringSSL, and OQS-OpenSSH will also need to be ready for review and merge by the time this is merged.)

[baentsch]

Thanks for the contribution. Is (possibly not correctly) supporting compilers this old really an issue, though? General question: Does liboqs really want to support compilers this old or rather add documentation and compiler version checks (for a certain minimum version) to minimize our efforts on outdated software? We also check for minimum cmake version, for example... Thoughts @dstebila @xvzcf @christianpaquin ?

Add: One of the CI failures in the Sphincs+ update are also related to a gcc > 7.1 version check (failing: It seems McElice code will not compile for gcc<7.1).

[dstebila]

I don't have a particular minimum gcc target in mind, but am agreeable to raising it unless we hear a strong demand and commitment to support.

[baentsch]

As agreed in our call, we rather prefer documenting and enforcing via CMakeLists.txt a minimum compiler version of 7.1, thus making this PR moot.

@distorted-mdw Please let us know if you know of a use case (for liboqs) where an older compiler would need to be supported.

[baentsch]

As discussed above, this PR is becoming superfluous when #1451 is merged and will be closed then.