Revise handling and testing of module-internal optimization options about mbedtls

[daverodgman]

This is something I've talked to @tom-cosgrove-arm about in the past. I suggested a general purpose MBEDTLS_SIZE_PERF_TRADEOFF type option, to give the user a single top-level tuning knob that they set to a number from, say, 1 - 5, to choose prioritisation between size / perf. My thinking was that this could automatically set up all of the fine-grained options, if they are unset, but the user could possibly have the option to over-ride them (e.g. set to 1 or 0). Tom was less keen on this approach.

[tom-cosgrove-arm]

I don't like a general-purpose performance config option, since users might well want to optimise one area for code size and another for performance. I do like the style of options introduced #8822 - they are fine-grained and can be set on the command line either way without getting overridden (a "default on" option needs either edit to the config file to be able to turn it off)

[gilles-peskine-arm]

I also favor a general size/perf/security tradeoff (security: some users are not concerned about timing side channels, so ideally they shouldn't pay for our easily-bypassed countermeasures like blinding). But when an option is contained in a small block of code, its cost is much less.