Create a mechanism for marking a configuration option as private.

• Private options must not be set by mbedtls_config.h, crypto_config.h or their alternatives and extensions (MBEDTLS_CONFIG_FILE, MBEDTLS_USER_CONFIG_FILE, etc.). Any attempt to test them is rejected with an #error raised whenever build_info.h is enabled.
• Nice-to-have: also reject private options passed on the compiler command line with -D.
• Private options may be set by adjust*.h headers.
• If MBEDTLS_ALLOW_REMOVED_FEATURES or TF_PSA_CRYPTO_ALLOW_REMOVED_FEATURES (as applicable) is enabled, then private options are allowed. These options are enabled in the full config, so it's ok to make an option private and default-off if our test coverage depends on it (e.g. removing an elliptic curve that is still used in test data).
• This applies to both TF-PSA-Crypto and Mbed TLS.
• Nice-to-have: complain if users try to define crypto options in mbedtls_config.h or X.509/TLS options in crypto_config.h. However, there must not be any complaints if the same configuration is used for both.
• Document a simple way to make more options private.
• Make legacy crypto options that are subsubmed by PSA_WANT_ private. (This may be done in a follow-up, but it's a good way to validate the new mechanism.)

The goal is to reject incomplete migrations of configurations from Mbed TLS 3.x. In particular, if the user attempts to set a legacy crypto option because of an incomplete migration from a configuration without MBEDTLS_PSA_CRYPTO_CONFIG, this should be rejected.

See “Strategy for removing a compilation option” in Mbed-TLS/TF-PSA-Crypto#145 (published soon) for further considerations.