Adding a speed_common script to benchmark OQS AES and hash algorithms

[tedeaton]

This adds a speed_common script, similar to speed_kem and speed_sig, but for benchmarking the encryption and hashing algorithms that liboqs uses. Specifically, it benchmarks AES128, AES256, SHA256, SHA384, SHA512, SHA3-256, SHA3-384, SHA3-512, SHA3-shake128, and SHA3-shake256. Currently it only benchmarks the main API of each of the hash algorithms, not the incremental version (that is something that could be added later if it's needed).

The script has a few options to change how it is run:
--msglen n : Each algorithm is benchmarked with a message length of n bytes (must be a multiple of 16 to benchmark AES)
--outlen n : For algorithms with variable-length output (e.g., shake128), specifies the output length.
<alg> : Only benchmark a specific algorithm.

Fulfills request in #1143

• 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 the list of algorithms available -- either adding, removing, or renaming? (If so, PRs in OQS-OpenSSL, OQS-BoringSSL, and OQS-OpenSSH will also be required by the time this is merged.)

[baentsch]

Thanks for taking on this issue! The logic in this PR departs from the pre-existing speed_kem|sig (and test_aes -b) apps though, in that it requires an algorithm parameter to run. Instead, not passing an algorithm name should lead to all algs being tested. Further, it would be prudent to have a default set of message lengths be run if that parameter is not given (analogous to openssl speed).

[tedeaton]

That should be how the script works already, unless I messed up the input parsing. If no algorithm is specified, then single_alg never gets set, and each algorithm should be run. Similarly, message_len is set to 64 bytes by default.

[baentsch]

That should be how the script works already

Sincere apologies: Indeed I overlooked that in the code and didn't actually run the code before. After doing this now, this is to confirm this PR indeed completely implements #1143. Thanks!