scheduler: fix checking conditional validity constraints on compressed domains

scheduler: fix checking conditional validity constraints on compressed domains

The original implementation would take a schedule on the compressed
domain and use it as if it were a schedule on the original domain,
possibly resulting in a missed detection of violated
conditional validity constraints.

This fix is based on code inspection.
It is not clear if the bug would ever trigger in practice.
The new test cases was specifically constructed by hand
to tickle the bug and only fails for the whole-component scheduler.

In particular, with conditions { B[1, i] -> A[0, i + 1] } and
conditioned validity constraints { A[0, i] -> B[1, i - 1] }
on domain { A[0, i] : 0 <= i <= 10; B[1, i] : 0 <= i <= 10 },
the whole-component scheduler would produce

domain: "{ B[1, i] : 0 <= i <= 10; A[0, i] : 0 <= i <= 10 }"
child:
  schedule: "[{ B[i0, i] -> [(i)]; A[i0, i] -> [(i)] }]"
  permutable: 1
  coincident: [ 1 ]
  child:
    sequence:
    - filter: "{ A[i0, i] }"
    - filter: "{ B[i0, i] }"

The single band violates the conditional validity constraints
since the conditions have distance 1 and
the conditioned validity constraints have distance -1.
With the fix, it produces

domain: "{ B[1, i] : 0 <= i <= 10; A[0, i] : 0 <= i <= 10 }"
child:
  schedule: "[{ B[i0, i] -> [(1 + i)]; A[i0, i] -> [(i)] }]"
  permutable: 1
  coincident: [ 1 ]
  child:
    sequence:
    - filter: "{ A[i0, i] }"
    - filter: "{ B[i0, i] }"

Here, both distances are zero.

Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>