The analyzer should indicate when it stops analysing a function

I want to open up a discussion about the usual case when a checker sinks execution paths and completely blocks the rest of the function from being analysed.
It only makes it worse if the user dismisses the issue that is sinking the execution path or uses `[[clang::suppress]]`.

The problem is that currently we don't have a way to call out this in any way for the user.
This frequently comes up with tiny tests when the user wants to learn the capabilities of the analyzer, and get surprised that we find anything but the first dereference - painting a pretty bad picture of us, despite that we are a lot more capable.

Here is an example: https://godbolt.org/z/j4aK575WE
```c++
void clang_analyzer_warnIfReached();
void f_nonnull(int * __nonnull p);
void f_nullable(int * __nullable p);
void test() {
f_nonnull(nullptr); // a trivial case to test if the analyzer is capable of reporting anything
// unfortunately, it also sinks the execution path...
clang_analyzer_warnIfReached(); // no-warning

// more tests to follow, in increasing complexity where we report nothing...
}
```

I think we should do something about it. Since the only way we can communicate with our users is via diagnostics, we should probably detect this case and report it.

Downstream example: rdar://169965382

Start with the Godbolt example and the clang_analyzer_warnIfReached() entry point, then examine why f_nonnull(nullptr) sinks the execution path and suppresses later analysis. No source file or test is named; done would require an agreed diagnostic design and coverage for the reported case.

Written by the indexing model from the issue text.