Dyno: implement manage statements & context managers

[DanilaFe]

This PR adds support for context managers:

manage bla as foo {
  // etc.
}

It does so by leaning on interface support, since we have decided to use them to "bless" the special methods enterContext and exitContext. As such, this PR depends on #26396 and #26471.

The diff without the interface implementations can be found here: https://github.com/chapel-lang/chapel/pull/26494/files/8c4102910462ff3e792bddaa75e01bdbf1b2ee63..a2e2745e3d47a65c284fb8119660288f028bbaa4

The general approach is straightforward: since we can compute witnesses for special interfaces like contextManager, this PR ensures that manage statements find the contextManager interface, and then use the witness functions as associated actions. Some complications arise due to the fact that context managers are design right now must be able to resolve return-intent-overloaded functions at manage time, which means (if the witness approach is to be used) that witnesses must contain all overloads. This PR adjusts for that, but only stores the additional overloads when ifc any return intent (the pragma that decorates enterContext) is used, thus attempting to avoid paying the multi-overload cost for other interfaces and functions.

Reviewed by @riftEmber -- thanks!

Testing

• dyno tests
• paratest

[riftEmber]

The manage technote and "manage statement" docs should be updated to reflect support for return intent overloading.

Also curious, what's the origin of the term 'witness' in this context?

[DanilaFe]

The manage technote and “manage statement” docs should be updated to reflect support for return intent overloading.

Return intent overloading existed prior to my PR (I’m merely mimicking production) — I can add a follow-up to check the docs, but I don’t think my PR made any changes to the semantics of manage statements on that front.

Also curious, what’s the origin of the term ‘witness’ in this context?

Logic! For propositions like exists x, P(x), the “x” (or abusively, the whole combination of x and a proof of P(x)) is called a witness. In fact, interface search in general is “merely” a proof search in first order logic. You can think of each interface as a predicate (N-ary where N is the number of formals), and each implements as an axiom that asserts the P(x) for the given type / interface combo. Generic implementation points like, for instance, someInterface(integral), are actually axiom schemas, under this correspondence.

This analogy typically comes from functional languages whose typeclasses are much like our interfaces. C.f. Haskell's typeclasses, Coq's typeclasses and Agda's instance arguments

[riftEmber]

Return intent overloading existed prior to my PR (I’m merely mimicking production) — I can add a follow-up to check the docs, but I don’t think my PR made any changes to the semantics of manage statements on that front.

Oh right, we're in dyno lol. All good then.

Logic!

Thanks for the explanation! I do remember that use of the term "witness" now, and the rest of it is new to me.

[bradcray]

Nice!