Add loop regions to the frontend's capabilities

[phschaad]

This PR lets the Python and Fortran frontends (optionally) generate LoopRegions for DaCe programs. This forms the third core element of the plan to make loops first class citizens of SDFGs.

This PR is fully backwards compatible. LoopRegions are always generated from new Python DaCe programs, and the legacy way of constructing a while / for loop is gone to remove complexity. To provide backwards compatibility, these LoopRegions are by default immediately inlined into a traditional single level state machine loop as soon as program parsing is completed, before simplification and / or validation. However, an optional boolean parameter use_experimental_cfg_blocks can be set to True when declaring a DaCe program in Python to enable their use, which skips this inlining step.

Example use:

import dace
import numpy

N = dace.symbol('N')

@dace.program(use_experimental_cfg_blocks=True):
def mat_mult(A: dace.float64[N, N], B: dace.float64[N, N]):
    return A @ B

# OR:
mat_mult.use_experimental_cfg_blocks = True
sdfg = mat_mult.to_sdfg()

The Fortran frontend similarly only utilizes LoopRegions if an additional parameter use_experimenatl_cfg_blocks is passed to the parser together with the program.

Many passes and transformations (including in simplify) do not yet have the capability of handling the new, hierarchical SDFGs. To not break the pipeline and to provide backwards compatibility, a new decorator @single_level_sdfg_only has been added, which can be (and has been) placed over any pass or transformation that is not compatible with the new style SDFGs. Passes annotated with this decorator are skipped in all pipelines where they occur and instead generate warnings that they were skipped due to compatibility issues.

For more information on LoopRegions please refer to the PR that introduced them.

Important Note about disabled tests:
Certain Python frontend loop tests have been disabled. Specifically, this concerns tests where either the loop structure (using continue/break) or other conditional statements cause the generation of control flow that looks irregular before the simplification pass is applied. The reason being that the frontend generates branches with one branch condition being set to constant False when generating continue / break / return, or while/for-else clauses. These branches are trivially removed during simplification, but not running simplification (as part of our CI does) leads to irregular control flow which is handled poorly by our codegen-time control flow detection. This error has so far gone unnoticed in these tests because of sheer luck, but is now exposed through a ever so slightly different state machine being generated by control flow region and loop inlining.

The goal is for a subsequent PR to completely adapt codegen to make use of the control flow region constructs, thereby fixing this issue and re-enabling the tests. For more information about the issue, see #635 and #1586.

Linked to: https://github.com/orgs/spcl/projects/10/views/4?pane=issue&itemId=42047238 and https://github.com/orgs/spcl/projects/10/views/4?pane=issue&itemId=42151188

[tbennun]

Not yet, need to discuss. Please answer questions in the meantime

[tbennun]

Make minor changes and feel free to merge.

[tbennun]

They may have empty contents bur are still @abc.abstractmethods. What was the intention?

[phschaad]

Initially the idea was to never instantiate a ControlFlowBlock - only subclasses of it, each of which being a graph (States and Control flow regions). However, with the change to use break/return/continue blocks, we now have blocks being used which should NOT contain further elements - so are no longer a graph. That's why these methods now all of a sudden need to not throw NotImplementedErrors. Or rather, they could be left as throwing those errors, but then at each point where we iterate over nodes of a graph we would need to make sure to not try and iterate into a control flow block, only into states and regions etc.

So that's the background - and now why I left the abstractmethod decorator: It should still be the case that you never instantiate a BlockGraphView directly and always explicitly subclass it. In 90% of use cases, that would mean implementing these methods here, since you would usually be making a graph type object.