feat[next]: Multiple output domains

[SF-N]

This PR builds on PR 2209. It enables the handling of multiple output domains in program and field_operator calls, which can either be explicitly specified or will be deduced.

Note: Prior to this commit, in the case of implicit domains (no domain argument), only a single domain was deduced which was assumed to be the same for all output fields. Now, every field gets its own domain, even when at runtime they are all the same.

Example:

@gtx.field_operator
def fop(a: IField, b: JField) -> tuple[JField, IField]:
    return b, a

@gtx.program
def prog(
    a: IField,
    b: JField,
    out_a: IField,
    out_b: JField,
    i_size: gtx.int32,
    j_size: gtx.int32,
):
    fop(a, b, out=(out_b, out_a), domain=({JDim: (0, j_size)}, {IDim: (0, i_size)}))

@gtx.program
def prog_no_domain(
    a: IField,
    b: JField,
    out_a: IField,
    out_b: JField,
):
    fop(a, b, out=(out_b, out_a))

[tehrengruber]

I made some cleanups in past_to_itir using two new arguments added to tree_map. Ready from my side as soon as we have decided and resolved on how to handle normalize_domains,

[havogt]

I just want to mark this non-mergable, because we need to double-check first if these changes don't have unintended side-effects on icon4py.

[edopao]

The dace lowering now works, also tested in ICON4Py CI. Tomorrow I will run a performance regression test on ICON4Py blueline.

@philip-paul-mueller Could you please review only the changes in the dace backend? Thanks

[philip-paul-mueller]

My main point of concern that a lot of checks is None where introduced, which I do not like at all.
They should have been filtered out before, this is what I would do/suggest.
If this is not possible, then some explanation, in doc strings, are missing what this mean.

[edopao]

Thanks @philip-paul-mueller for the review. I will now push an updated version of the SDFG lowering, which addresses your comments. However, I will pull part of the changes into a separate PR, which can be merge separately, before this PR.

[edopao]

@philip-paul-mueller The dace part is ready for another round of review.

@havogt Yesterday I ran a performance regression test on icon4py blueline and I see no issues, see plot.

[philip-paul-mueller]

I think the lowering is kind of okay, some refactoring might be needed.
Although I still do not like the Nones but the explanation makes it clear what is going on.
I have some smallish suggestions.

[philip-paul-mueller]

The lowering part looks good to me.