[clang] [analyzer] Introduce the check::BlockEntrance checker callback (PR #140924)

[Balázs Benics via cfe-commits]

balazs-benics-sonarsource wrote:

> What is the relationship of this new callback with the `BranchCondition` callback which is evaluated in `ProcessBranch` where the checker splits the execution path into multiple branches? It would be nice if you could document the difference between these two callbacks.

Great question. They are for different purposes, but one should prefer `BranchCondition` over the strictly more generic `BlockEntrance` callback. State splits work as in any other checkers. If you split the state in both callback, you will end up with 4 splits for the cases that are `if`, `for`, `while`, statements with conditions and 2 paths for every other control-flow edge, like entering the first basic block from the Entry CFG node, or following a `break`, `continue` or `goto` (unconditional) CFG edge.
Documented this now in c2bd657065e0edcac742941c1a535444a90b1638, and added a unit test for the case when both callbacks are defined in 910abb384af9c8d51f32d2109a73ab900682957e.

> > What is the relationship of this new callback with the BranchCondition callback
> 
> +1, I am also interested to learn what is the main motivation behind the new callback. Do you have some example use cases in mind? I think users might get confused which one to use.

My motivation is to drive enabling or disabling an internal checker by entering or leaving a certain CFG block.
Concretely, if a short-circuiting operator leads to the guarded CFG block (aka. the true branch for the `&&` operator and the false branch for the `||` operator), enable a checker to detect certain constructs in a guarded block. And once we are leaving the guarded block disable the checker. I hope it clarifies the motivation and demonstrates the usefulness of such a callback.

I believe that there could be other similar use cases of this.

https://github.com/llvm/llvm-project/pull/140924