[clang] [clang][analyzer] Add OpaqueSTLFunctionsModeling (PR #178910)

[Endre Fülöp via cfe-commits]

gamesh411 wrote:

> > Note that we have [trouble with matching some sort functions directly](https://github.com/llvm/llvm-project/issues/78132#issuecomment-2028445993). If I understand it correctly, that only affects `std::ranges::sort` and not `std::sort` but I'm not sure -- and maybe @gamesh411 decided to match the internal functions because he was scared of that.
> 
> Yea, we can't match [niebloids](https://brevzin.github.io/c++/2020/12/19/cpo-niebloid/), but I think matching the internals is even worse because that is tied to a very specific STL implementation. IMO that is strictly worse.

I was aware of the hurdles here https://github.com/llvm/llvm-project/issues/78132#issuecomment-2028445993, but that was only part of the reason for this implementation.
First, I may have went too far and placed every suppression from the `LikelyFalsePositiveSuppressionBRVisitor` (minus the macro-related suppression of <sys/queue.h> and the option-driven suppression: `ShouldSuppressFromCXXStandardLibrary`). This means I had all the `std::list`, `std::shared_ptr` and `std::basic_string` methods in this checkers `evalCall`.
But that broke the modeling we have for those in other checkers, namely in `ContainerModeling` and `IteratorModeling`. So, for sure there are some use-cases that cannot be handled by `evalCall`-ing them like this, and I was not thinking through the effects of that change deep enough.
Then I concluded that it is not an option to migrate those suppressions into this modeling checker, because modeling with `evalCall` here interferes with modeling them elsewhere. I think the same could be said about the "public API" of the sort functions the `std::sort` and co. If we `evalCall` those, we cannot model them elsewhere, so that leaves us with suppressing the problematic internals.

Now, maybe in this `OpaqueSTLFuncstionModeling` checker we could match for a parent-context that matches the "API-public" signature, but still suppress the current internal function call? That way we can avoid naming the internal function, but can still suppress it. Would that be better, WDYT? @steakhal @NagyDonat 

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