Dyno: fixes to make sync tests resolve

[DanilaFe]

This PR fixes some sync tests which were failing for various reasons.

• A couple of the tests were failing because an enum was named e. It turns out our logic for compiler-generating enumeration types ends up creating the following:

  proc chpl__enumToOrder(e: e) { /* ... */ }

  In this case, the declaration for the formal e was picked up in the type expression, and we ended up with a use-before-def. In production, I'd resolve this by creating a direct SymExpr to refer to the enum type instead of the formal; in Dyno, lacking the ability to short-circuit scope resolution in this way, I simply rename the formal to e_ in this case.

• Some tests were failing because copying out of a sync produced a sync instead of implicitly performing a read. In this PR, I used Ben's infer copy type pragma Allow for inferring custom type #22308 to customize the behavior here, enabling the reads. However, in production, this produces a warning, so...

• I implemented the "implicit sync reads is deprecated" warning. Last time I tried getting rid of the implicit sync reads (since they are past their deprecation duration), I found them to be load bearing, so I chose this approach instead. This required some changes...

  • I converted the ConversionKind (for canPass) into a bitfield. This way, we don't have to separately encode borrows and borrows subtype (borrowing is now a flag), and I can encode an additional type of conversion kind: reading a sync. Thus, we may pass a sync owned Child to a borrowed Parent by borrowing, reading, and applying a subtyping conversion.
  • To implement this warning for formal/actual pairs, I matched the existing approach for disallowing coercions for ref: storing the conversions in the MostSpecificCandidate. This is required (as opposed to issuing the warning from canPass directly, say) to avoid spurious warnings where a conversion would take a place if a different candidate was selected, but where that candidate was rejected for a different reason.

This is the net result. I consider it an IOU to decide when to issue the warning for implicitly reading from a sync into a variable (as opposed to a formal), but that is IMO secondary to getting sync types behaving as expected.

Reviewed by @arifthpe -- thanks!

Testing

• dyno tests
• paratest --dyno-resolve-only
• paratest