This is inspired by https://bugs.llvm.org/show_bug.cgi?id=42780, even though it doesn't fix the bug.
If the global variable has an initializer, we'll ignore it because we're normally not analyzing the program from the beginning. This means that a global variable may have changed before we start our analysis.
However when we're analyzing main() as the top-level function, we can rely on global initializers to still be valid. At least in C; in C++ we have global constructors for breaking this logic. In C we can also have global constructors as a GNU extension, but i'd rather not worry about that.
In this patch i don't try to evaluate global initializers; the patch only covers the case when they're constants. This is the reason why we don't cover https://bugs.llvm.org/show_bug.cgi?id=42780, however we could cover it if SValBuilder.getConstantVal() was a bit more feature-rich (namely, we need to be able to constant-evaluate expressions like &var.field where var is a global variable; it's a concrete region (i.e., without symbolic base) value in our model, so we can make getConstantVal() powerful enough to emit it).
For initializers of fields and elements i'm piggybacking on @r.stahl's work to cover global constant initializers (D45774).
The main benefit of this patch is to make it harder for people to send us false positive reproducers that don't actually reproduce the false positive that they're having :)
We could have put this flag into RegionStoreManager instead - after all, it doesn't change for the whole duration of the analysis. It would have made it easier to handle (avoid weird bitwise logic) and probably cheaper, but it'll make the manager needlessly stateful (which wouldn't really hurt at all right now, just looks ugly).