Separate binding insts for refs and values

[geoffromer]

This resolves a TODO in expr_info.cpp by using the inst kind rather than the bound value to track the binding's category.

Since we're churning all the bind_name insts in testdata anyway, I'm also taking this opportunity to align the inst naming with the design's terminology, by calling these insts "bindings" (this aspect of the PR is dependent on #6231 resolving an ambiguity in that terminology). For consistency we'll need to rename several other insts as well (see the TODO on RefBinding); I'm deferring that to a separate PR to minimize the review load, but I think those name changes are in-scope for this review.

[chandlerc]

The code changes seem generally fine here to me. I skimmed a bunch of the test updates and they all made sense. I didn't try to get GitHub to open literally all of them though.

My biggest question is whether this is the right model that we want in SemIR. Specifically, this appears (unless I misunderstand, sorry if so) to make all of the binding patterns in var patterns into ref_binding_pattern insts. Are we happy with that, and walking back through to discover that these aren't just ref bindings (as created by let ref name: T or something, but specifically ones referring to a variable? We can also come back and revisit it, but would be good to get a gut check from @jonmeow or @zygoloid on the SemIR model itself here.

[chandlerc]

If this is dependent on proposal #6231, it seems odd to reference it in a TODO?

[geoffromer]

How so? I feel like it's pretty normal to have a TODO that basically says "implement this proposal".

In any event, I'm happy to drop it if you prefer. It was really meant for the reviewer to begin with, and I intend to resolve it as soon as possible.

[geoffromer]

Specifically, this appears (unless I misunderstand, sorry if so) to make all of the binding patterns in var patterns into ref_binding_pattern insts. Are we happy with that, and walking back through to discover that these aren't just ref bindings (as created by let ref name: T or something, but specifically ones referring to a variable?

That sounds like the opposite of my intent. The basic idea of this PR to to model the different kinds of binding patterns using different inst kinds, rather than leaving that information implicit in the inst graph. It doesn't use different inst kinds for ref bindings than for bindings nested under var because as far as I know there is no semantic difference between them (not to mention the fact that the toolchain doesn't support ref bindings yet).

Proposal #5545 does give special treatment to some bindings under var (specifically, "variable binding patterns", when the binding is the entire subpattern of a var pattern), but I don't think I can model that in this PR because the differences pertain to things like move semantics that aren't implemented yet (plus, that proposal hasn't been adopted yet). When we do implement those differences, I'm not certain we'll use a separate variable_binding_pattern inst kind, but that seems likely, and this PR is certainly intended to leave that option open, if not actively encourage it.