[clang] [NFC][analyzer] Introduce specialized variants of makeNode (PR #194459)

[Donát Nagy via cfe-commits]

NagyDonat wrote:

> Can we revisit this later in the future?

This change is a bottleneck in the `NodeBuilder` removal process, because I intend to use the methods introduced here (`makePostStmtNode` and `makeNodeWithBinding`) as replacements for 60% of the `NodeBuilder` usage (these are solutions for very common patterns). I can create a few unrelated commits like https://github.com/llvm/llvm-project/pull/194843 but I will run out of those soon.

However, this whole `NodeBuilder` removal is not especially urgent, so it is OK if it is delayed for a month – but I don't want to postpone it indefinitely.

By the way @steakhal could we perhaps reduce your review burden by involving another reviewer? E.g. I could ask @tigbr to verify that the new code is equivalent to the old one, and then you would only need to provide a high-level design/architectural review instead of a detailed inspection.

-----

RE: your concerns:
> * The new API does not simplify the old uses too much.

These changes do not make the code shorter, but they do eliminate the set manipulation side effects that are very hard to reason about. (This is not just a theoretical concern – soon I will publish two unrelated non-NFC commits to fix logic errors where the coder misunderstood `NodeBuilder`s.)

Replacing these `NodeBuilder`s with plain low-level `makeNode` (instead of the new methods) would _increase_ the length of the code and hide the existence of frequently reoccurring patterns. (There will be 20+ calls to `makePostStmtNode` and 30+ calls to `makeNodeWithBinding` at the end of the refactoring.)

> * Binding can mean two different things: for exprs and for stores; so it is till a bit ambiguous - albeit the Expr somewhat disambiguates this.

Yes, I agree that this is unfortunate, but I couldn't pick a better name. (I thought about `bindExprInNode`, but I felt that it doesn't express that it _makes_ a node.) I'm happy to use another name if you have a good idea.

> * The custom `insert` calls made me look harder for semantic equivalence.

Yes, these transitions are more complex because:
- The "primary" (4 parameter including MarkAsSink) `generateNode` was a reasonable API, so I introduced `makeNode` as an 1:1 replacement for it.
- The 5-param `generateNode` is not that comfortable, so in this commit I introduce a better API as its replacement.

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