Dyno: implement field access promotion

[DanilaFe]

Closes https://github.com/Cray/chapel-private/issues/7227.

This PR implements field access promotion; that is, we can now resolve code like this:

record pair {
  var first: int;
  var second: real;
}
var A: [1..10] pair;
var B = A.first;
var C = A.second;

I ran into issues implementing this naively, and took a look at how production does this. However, as I discovered in #26938, production doesn't implement this feature properly, either!

In both Dyno and production, fields are accessed using their "getters". From there, promotion works the same as it does with anything else (by finding methods that apply to the element type, and creating wrappers). The crux of the issue is that we need to "discover" the getters in the current scope. Production does this incorrectly: it searches the scope in which the promotion would occur, and it searches the scope of the receiver. However, it does not search the scopes of the scalar elements. This leads to the bug discoveed in 26938.

The proper way to handle this situation is to find and check the scopes of the scalar types. However, to do this, we need to know the scalar types! This requires us to resole chpl__promotionType. The PR does just that: if we can't find regular candidates, and if we can't find forwarded methods, for parenless method calls, it computes the receiver's scalar type and searches it for receiver scopes.

This leads to problem with recursion. In general, we always try to firs resolve code like x.foo() as (x.foo)(), which means we try to find foo as a field. This often does not succeed (particularly if x.foo is a function). However, x.foo matches all the conditions in the preceding paragraph. This means that, naively, we end up with recursion as follows;

1. We attempt to resolve a type's chpl__promotionType method
2. This method exists, and has a method access (e.g., this.isRectangular())
3. We attempt to resolve this.isRectangular as a field, and we don't find it.
4. We try to find this.isRectangular in the scalar types, which requires resolving chpl__promotionType.

This PR takes the "naive" approach that we take elsewhere: using isQueryRunning. Notably, there is an open concern with isQueryRunning as a whole, well-documented in #26459. However, a "proper" resolution to this issue would be very involved or very performance-heavy.

Reviewed by @benharsh -- thanks!

Testing

• dyno tests
• paratest