`can_deref` can unintentionally mask genuinely invalid memory accesses in ITIR

[tehrengruber]

This problem is a little convoluted to describe in a generic fashion, I'm just leaving the specific example for later investigation.
Consider the following stencil:

neighbors(C2Eₒ, (↑(λ(__arg0) → cast_(·__arg0, float64)))(⟪Koffₒ, -1ₒ⟫(__stencil_arg2))))

This stencil is only valid when when __stencil_arg2 can be derefed with a Koff of -1. However now consider we unroll the neighbor reduction we become

λ(_acc_10, _i_11) → if   can_deref(⟪Koffₒ, -1ₒ, C2CEₒ, _i_11⟫(__stencil_arg1))
                    then _acc_10 + ·⟪Koffₒ, -1ₒ, C2CEₒ, _i_11⟫(__stencil_arg1)
                                   × cast_(·⟪Koffₒ, -1ₒ, C2Eₒ, _i_11⟫(__stencil_arg2), float64)
                    else _acc_10

Now suddenly this is unconditionally valid as can_deref will just mask the previously invalid accesses in K.

[havogt]

My view on this would be:

1. since GT4Py aims to be user-friendly, we need to catch this error at least in debug execution (which I'd say will be embedded eventually)
2. (obviously influenced by my C++ background) since the original code is invalid, any version is invalid, even if it executes without error.

In conclusion, I don't see a problem, except that we should improve on part 1.

Or do you think there is something we should do in icon4py to fix that?