dyno: implement opaque extern types

[DanilaFe]

This PR implements opaque extern types in Dyno. An opaque extern type is one defined as follows:

extern type myType;

Types like these are "opaque" in the sense that Chapel doesn't know their underlying representation; the name is pretty much the only identifying information about such types.

This PR diverges from production compiler behavior in that extern types with the same name are considered equal, even if they were declared in different places. In other words,

proc f1() type {
  extern type myType;
  return myType;
}

proc f2() type {
  extern type myType;
  return myType;
}

param x = f1() == f2(); // false in production, true with this PR

Reviewed by @benharsh -- thanks!

Testing

• paratest

[benharsh]

Generally looks good, but I think we need to address the linkage-name vs. original-name question.

[benharsh]

I think this is left over from development.

[benharsh]

I believe we need to preserve both the linkage name and the Chapel name. If a user writes:

extern "helper_t" type helper;
writeln(helper:string);

Then I believe it should print "helper" (and does in production, fwiw).

[benharsh]

Adding a test that checks the stringify'd name of extern types would also be useful.

[DanilaFe]

Discussed this out of band, and Ben and I agreed that we can merge the PR as-is for the time being, and figure out how to keep the original name as part of the type later.

We don't want to show linkage names to the user instead of the Chapel type name, so this feature is important in the long term.

The reason this doesn't immediately work is that our type comparisons in canPass are based on pointer equality; however, if we were to store the ID or name of the variable that declared an opaque type in addition to the linkage name, two variables with distinct Chapel names but identical linkage names would not be the exact same type, and thus become incompatible. We don't want that. To address the issue, we probably want to do a deep comparison on types.

[DanilaFe]

This is also tracked here: #22711