[clang] [analyzer] Update the undefined assignment checker diagnostics to not use the term 'garbage' (PR #126596)

[Donát Nagy via cfe-commits]

NagyDonat wrote:

> This is a sufficiently strong contract in the static analyzer; I'm not aware of any long-lived undefined values and I'd consider it a bug if I ever see a long-lived undefined value. I'm pretty sure there are a few assertions that would crash if this ever happened.
> 
> So you can try to rely on this implicit contract to send a stronger message. For example:
> 
> ```diff
> -    ++x; // expected-warning{{The expression is an uninitialized value. The computed value will also be garbage}}
> +    ++x; // expected-warning{{Uninitialized variable incremented}}
> ```
> 
> ```diff
> -    int y = x; // expected-warning at -1{{Assigned value is garbage or undefined}}
> +    int y = x; // expected-warning at -1{{Value of uninitialized variable assigned}}
> ```
> 
> ```diff
> -    b.x |= 1; // expected-warning{{The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage}}
> +    b.x |= 1; // expected-warning{{Uninitialized variable used in compound assignment}}
> ```

On the other hand, directly saying "uninitialized" could be a good direction because it's more concise and you're right that it's pretty much the only source of `UndefinedVal`s in the analyzer.

> (You might want to make a distinction between variables and fields. But even if you don't, it's not unreasonable to simply say "variable" unconditionally, even without looking at the exact expression. You can use the word "location" if you're worried about locations of exotic nature. But you can be fairly certain that it's always going to be _a_ location, not any other source of values.)

I'd suggest writing "uninitialized memory" to (1) support the common case where the memory comes from `malloc()` et al. and (2) dodge the distinction between variable/field/etc.

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