build[next]: rollback gt4py-next to dace 1.0.0, keep cartesian on dace 1.0.1

[edopao]

Dace was upgraded to version 1.0.1 to fix a bug in ConstantPropagation in GT4Py cartesian. However, the updated ConstantPropagation transformation breaks code generation for GT4Py next.
This PR does rollback of dace version just for GT4Py next. A deeper investigation of the breaking change will be done later, on dace main branch, because for GT4Py next we plan to pull dace from the git repository.

[philip-paul-mueller]

This is very strange as gt_simplify() is written to explicitly such that this pass is not run by default and as far as I know, we do not call it explicitly anywhere.
So if it is really constant propagation, then it is a violation of ADR18, which clearly states that calling naked DaCe simplify directly is undefined behaviour.
So we have to find this location and remove it.

[philip-paul-mueller]

I think the best way to find this would be to put an assert in SDFG::simplify() and then attach a debugger.
This works because our pipeline does not use this function.

[edopao]

I know the exact location. The location is in the PR still to be merged #1818. There I call gt_substitute_compiletime_symbols() when the range start symbols have to be fixed to zero at compile time. Indeed, the only tests that fail are those in dace orchestration, where this option is turned on.

[philip-paul-mueller]

You are absolutely right, I call the transformation there, to handle a case.
But then it is a bug and I myself violate the ADR.

I do not like the current implementation of this function anyway, I opened an issue and think of a solution to avoid that.
There is even a DaCe issue that is related to this problem.

[edopao]

dace 1.0.1 is probably not the issue.