Dyno: make VarScopeVisitor analyses work per-tuple element

[arifthpe]

Adjust VarScopeVisitor and the analyses implemented using it (call-init-deinit, copy elision, split init) to operate per-tuple element, as appropriate.

---

Explanation of approach

The main strategy here is to treat each tuple component within a tuple destructuring decl/assign as though it was a decl/assign of an individual variable, e.g., var (a, (b,)) : (int, (real,)) = (1, (2.0,)); will be treated similarly to var a : int = 1; var b : real = 2.0;. VSV is adjusted to gather information on tuple decls/assigns as it goes (including nested tuples), but not holistically process them as decls/assigns. That processing only happens once each individual VarLikeDecl/Identifier contained within is reached, using info propagated from surrounding tuples to provide a pseudo- init-part and type-part as though it were a standalone decl/assign. As part of this approach, decl/assign handlers in VSV subclasses are refactored to accept a separate LHS and RHS rather than an actual decl/assign AST node, so they are agnostic to actual standalone decl/assigns vs the pseudo ones presented for destructured tuple elements.

There are a few changes to the output of VSV analyses to accommodate tuples:

• Copy elision now outputs a map of (init point ID) -> (moved-from ID), rather than just a set of init point IDs. This allows representing tuple decls/assigns in which multiple RHS components are copy-elided from.
• The ID stored for an assignment where copy is elided is now the ID of the LHS of the assignment rather than the ID of the assignment itself. This is to represent tuple destructuring assignments, where multiple LHS components of the same assignment can have values from the RHS copied/moved into them. For consistency, it also applies to real standalone variable assignments as well as to tuples.

With this change, AssociatedActions are now generated for each tuple element as appropriate, and can be different for each element. It also includes additions to AssociatedAction itself, to accommodate cases where there is an Action on the tuple as a whole as well as its components:

• A tuple element index field, to indicate which tuple element the Action applies to when there is no actual AST for each element.
• A sub-actions field for Actions which contain others in a hierarchy. This is currently only used for tuples, but could also apply to other hierarchical Actions in the future if we add any.

An example where the above changes are relevant is the following:

record R { }
var r = new R();
var tup = (1, r);
var x = tup;
tup;

Here we would record an INIT_OTHER for tup which contained an ASSIGN and MOVE_INIT sub-action for its elements, respectively. Then we would have a COPY_INIT for x which contained an ASSIGN and COPY_INIT for its elements, respectively, and since there is no RHS AST to store the IDs of in the sub-actions to keep track of which action belongs to which element, we would store the element indices.

A major drawback of this approach is that it does not elegantly handle the case of a (non-destructuring) tuple variable LHS and a tuple expression RHS, like var myTuple = (a, b);. The VSV changes are centered around traversing the LHS and creating an equivalent decl/assign for each LHS component, but in this case there is no AST to traverse that represents the tuple elements. However, some VSV analyses still need to handle a tuple expr RHS on a per-component basis, such as noting variable mentions and finding elided copies. This PR does so by adding special behavior to each of the VSV subclasses which need to do such handling. Some alternatives considered were:

• Resolving a generated init=/= call on the tuple which would perform per-element initialization/assignment. This should give us handling of copy elision etc for free, as each RHS component would be an argument to the call and processed as those normally are. I'm not sure if this approach could also cover the destructuring decl/assign case well. I didn't look into this route because I didn't think of it until Ben suggested it when I asked for input, by which time I had already nearly finished the VSV subclass special behavior approach.
• Traversing the RHS of such decl/assigns in VSV, and generating a pseudo standalone decl/assign for each LHS/RHS component pair. Since there is no LHS component AST it wouldn't fit perfectly into the approach of making VSV analyses agnostic to tuple component init/assigns, and likely require some more adjustments to each analysis. I partly implemented then abandoned this approach due to its excessive complexity.
• Some other approach which unifies both the destructuring and non-destructuring decl/assign cases, so both can be presented as pseudo-standalone decl/assigns per-element to the VSV analyses. I was unable to come up with a way to do this that wasn't way more complicated than it's worth.

This PR also reverts the change from #27533 which changed tuple expressions containing any refs from CONST_VAR to CONST_REF kind, as discussed from #27533 (comment).

---

Contributes to https://github.com/Cray/chapel-private/issues/6283.

Future work:

• Add DEINIT for tuples (part of https://github.com/Cray/chapel-private/issues/6283). Not included due to the size of this PR.

Note to reviewer: The commit history of this branch is a mess due to abandoning an earlier approach, so it'd be best to review the diff as a whole.

[reviewer info placeholder]

Testing:

• dyno tests
• paratest

[DanilaFe]

Yay, marked non-draft!