[clang] [analyzer] Introduce the invalidation artifact symbol (PR #207155)

[Balázs Benics via cfe-commits]

steakhal wrote:

> > Behaves like SymbolConjured but additionally carries an InvalidationCause describing why the invalidation happened, and (when known) the symbol that was bound to the region just before the invalidation.
> 
> I think it is clear that these two classes have some shared behavior (which is not shared by other symbols) -- for which the theoretically accurate model (which prevents code duplication) would be introducing a common parent class for them.
> 
> However, if I understand correctly, `SymbolConjured` wouldn't have any additional behavior compared to this common parent, so we would get a situation that is very close to "SymbolConjured is a parent of InvalidationCause" (but you would have the separate type `class SymbolConjured : public ConjuredOrInvalidation` for values that are known to be "real" conjured values).

I'm open for suggestions. I also agree that having something similar to conjured would make reasoning more difficult and be a source of confusion.
I primarily want to avoid a situation where we can be unsure if this invalidation metadata is present and to what extent it's present.

I could repurpose conjured symbols for this, and shove this metadata into it. WDYT about this? @NagyDonat @Xazax-hun 
I could explore this direction.

---

> Are you planning to develop some practical applications of this new functionality in the foreseeable future? (I really hope that it won't end up as dead code.)
> 
> I didn't think too deeply about the details of the changes, but most of them are boilerplate and I feel that even the AI won't mess up such trivial modifications.

I already have a niche checker-specific FP suppression patch in the pipe using this, proving the value. That prompted me playing with the idea of implementing this proposal.

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