Option to warn for each inserted runtime check that can't be proved unnecessary

[secure-sw-dev-bot]

This issue was copied from microsoft/checkedc-clang#1188

---

I propose that the compiler should have an option to report a warning every time it inserts a runtime check that can't be proved unnecessary. (The warning could be upgraded to an error via an appropriate -Werror=... option.)

Potential benefits of this feature:

1. In combination with erasable syntax (Issue to track comments and updates to the proposed Checked C extension changes. microsoft/checkedc#470), a user could get a guarantee of spatial memory safety of a program compiled with a plain C compiler if they compile the program with the Checked C compiler and there are no "runtime check needed" warnings.
2. A user can see where the program might get a SIGILL at runtime and consider whether they want to add code to handle the error condition more gracefully.
3. A user can see where runtime checks are being performed as a starting point to investigate the performance impact.
4. IIUC, currently, certain potentially risky operations in Checked C code (e.g., pointer dereferences) silently generate runtime checks, while other such operations (e.g., pointer copies for which bounds implication can't be proved) generate a warning and no runtime check. This design difference was one of the things I found most confusing as a new user learning Checked C. The proposed option would take a step toward harmonizing the treatment of both kinds of risky operations. We could consider further steps in that direction, such as optional automatic insertion of _Dynamic_bounds_casts on pointer copies where bounds implication can't be proved (where possible, e.g., only if all the information needed to perform the check is available at runtime).

To implement the feature, if my understanding is correct that the compiler currently doesn't do any analysis of the necessity of runtime checks and leaves it to a later LLVM optimization pass, the compiler would need to do that analysis during the main Clang semantic analysis phase, as it does for checking bounds implication when a pointer is copied. I hope that wouldn't be too hard. For a pointer dereference, I imagine it might be possible to reuse the existing bounds implication logic to check whether the declared bounds imply the bounds of the element being dereferenced; for null checks, I'm not sure.