Investigate clang-tidy on the CI

[gilles-peskine-arm]

clang-tidy can run many sanity checks (linting) on our code base. This has come up before in the context of style checks, but there are also semantic checks that could be useful.

Some examples of potentially useful checks:

• Maybe some style checks (see discussions in Investigate coding style automatic check and enforcement #4668 and Investigate clang-format limitations #6345), but we're using a different tool (uncrustify) so clang-tidy may be superfluous here.
• Replace part of check_names.py, if this allows us to get rid of some complex code and to have fewer false positives or false negatives.
• Maybe replace component_build_zeroize_checks with bugprone-sizeof-expression.
• bugprone-macro-parentheses has come up before, we periodically fix unhygienic macros that reviewers missed.

The goal of this task is to:

• Either conclude that clang-tidy is too much cost for too little benefit, or add a run of clang-tidy on the CI. (TBD: in what configuration(s)) If we decide to run clang-tidy...
• Define an initial set of checks.
• Retire any ad hoc code that is made obsolete by the initial set of checks.
• Figure out how to work around false positives.
• File issues to investigate more checks.