unified: improve node locations

[tausbn]

Changes the location-assigning heuristics to implement roughly the following principles:

• A node that is translated recursively gets its location assigned first, and this location is not modified by the outer rule. (However, it can affect the outer location.)
• If an intermediate node is synthesised (e.g. middle in (outer foo: (middle bar: {baz}))), then it gets a location that spans all of its children (that is, all of the captures that have already been translated, that are assigned as descendants of this node).
• If an intermediate node has no children that give it a location (and the location is not otherwise set), it gets an empty location at the start of the node that led to this rule match in the first place. (Thus, it's generally in the correct area, even if there isn't a specific bit of source code we can point to as the appropriate "location".)
• The outermost node of the rule body (i.e. outer above) gets the location of the entire node that matched that rule (unless that location has been assigned already, e.g. by recursive translation or explicit assignment).
• Interpolated node IDs carry their location. If you write (identifier #{name}), where name is some captured node ID, then the identifier node gets the location of that capture, whereas the string value is what is actually interpolated.
• If a node is constructed with an explicit location, that location is respected and is not subsequently widened to the entire rule match.

One consequence of the above rules is that if you have something like

(foo bar: @baz) => expr {baz}

then the location of the node emitted by the right hand side is not that of foo, but rather whatever is assigned to baz when it is recursively translated.

In cases where this heuristic is insufficient, newly added tree_at! and tree_spanning! macros may be employed. These take a second argument that specifies the node (or iterable of nodes) from which to take the location of the tree being constructed.

---

Should be reviewed commit-by-commit. I checked a bunch of the location changes in the last commit manually (and instructed Copilot to check the rest). In all cases, the locations are an improvement on what was there before (e.g. a call inside a tuple accidentally including the following , in its range). This does produce a fair amount of churn, but I think it's somewhat unavoidable.