dyno: Initial resolution of `zip()` expressions and parallel iterators

[dlongnecke-cray]

This PR introduces resolution for zip() expressions as well as resolution of parallel iterators for forall and [] loops.

For zip() expressions that appear as the iterand of a serial loop, the strategy is to resolve only serial iterators for each actual in the zip().

For zip() expressions that appear as the iterand of a forall loop, the strategy is to:

• For the first actual (known as the leader), attempt to resolve a suitable leader iterator or error
• For the leader and all remaining actuals (known as followers), attempt to resolve a suitable follower iterator or error

For [] loops, the strategy is similar, except serial iterators may be used as a substitute for the leader and followers IFF the leader iterator could not be resolved for the first actual. If the leader iterator could be resolved, but e.g., its return type could not, then serial iterators will not be considered as fallbacks.

For iterands that are not zip() expressions, the "standalone" parallel iterator is preferred for parallel loops before attempting to resolve a leader/follower combo. As with zip(), forall loops will emit an error if no form of parallel iterator could be resolved. All other loops will fall back to serial iterators.

Thanks to @vasslitvinov for walking me through the semantics of zip() and parallel iterator resolution.

FUTURE WORK

• Iterator forwarding for iterators in the internal modules (e.g., tag=tag, followThis=followThis)
• Expand tests, handle edge cases, attempt to resolve leader/follower/standalone iterators for standard/internal types

Reviewed by @DanilaFe. Thanks!

[dlongnecke-cray]

I'll fix the CI check failures tomorrow, have to head out for the night.

[dlongnecke-cray]

Adding isSerialIterator isLeaderIterator isFollowerIterator and isStandaloneIterator as per your suggestion.