[clang] [analyzer] Handle [[assume(cond)]] as __builtin_assume(cond) (PR #116462)

[Balazs Benics via cfe-commits]

steakhal wrote:

I was thinking about the case, and I think it's okay to have state-splits in the subexpressions coming from an assume expression - given that the assume expression has no side effects.
This way we should have 2 paths after the assume expression (but still before the first if statement).
1) where `a > 10` is true
2) where `a > 10` is false, aka. `a <= 10`.

This is I think the current behavior of your proposed implementation. Could you demonstrate it in tests?

Something like this should prove it:
```c++
int ternary_in_assume(int a, int b) {
  [[assume(a > 10 ? b == 4 : b == 10)]];
  clang_analyzer_value(a); // we should have 2 dumps here.
  clang_analyzer_dump(b); // This should be either 4 or 10.
  if (a > 20) {
    clang_analyzer_dump(b + 100); // expecting 104
    return;
  }
  if (a > 10) {
    clang_analyzer_dump(b + 200); // expecting 204
    return;
  }
  clang_analyzer_dump(b + 300); // expecting 310
}
```

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