[Arith] DetectIterMap support overlapped iteration sum

[wrongtest-intellif]

The change wants to support detect non-bijective iteration sum like h + kh or 4 * i + j, j in [0, 6) etc. Previously they would not pass DetectIterMap either in bijective or surjective mode.

IIUC, one of the DetectIterMap's main concentration is on iteration bindings which can perfectly split/fuse from loop index vars, however, there are also a wider range of applications on memory access indices analysis and non-perfect tilings. Thus it would be great that certain index patterns could also get supported. For example,

• h + kh: an index pattern common in stride=1 convolution or poolings.
• 4 * co + ci, ci's extent is larger than co's scale: typically occurs in overlapped input tiles.

Currently they are not supported in TryFuseIters routine of DetectIterMap, since scales are strictly checked here. If we have 4 * co + ci, the ci's extent must be 4 to match next iter(co)'s scale. The PR try to relax it in surjective mode.

For example, the iteration sequence of 4 * co + ci (co in [0, 3), ci in [0, 5)) could be:

0, 1, 2, 3, 4; 4, 5, 6, 7, 8; 8, 9, 10, 11, 12

Thus it is "surjective" on range [0, 3 * 4 + 1) = [0, 13).

For the existing cases, the effects seems to be:

1. Some cases which expect failure now pass, mainly because block's affine flag depends on the surjective-ness check.
2. The split primitive testcases create many i + j patterns, they now get handled differently, which affects expected block binding expression.
3. Due to (2), two of the basic meta-schedule case's expected block binding expression also changed.

[wrongtest-intellif]

cc @vinx13 @spectrometerHBH @Hzfengsy
Also fix me if it affects other parts, like original semantic of affine flag, or inverse iter map detections. Thanks very much!

[Hzfengsy]

Could you please take a look at it? @spectrometerHBH

[gigiblender]

This caused the CI to fail and was therefore reverted by #12137.