Address a subtle mismatch involving what loop bounds the code thought

were implemented.

The issue comes from the fact that a loop bound predicated on a
parameter such as

[n] -> { [(-1 + n - floor((3n)/4))] : n > 0 }

(which may result from slabbing) will be converted by pw_aff_to_expr()
to an unconditional expression, even though the original pw aff is
conditional. As a result the previous code might not actually ensure
that n > 0.

(In prior versions the issue was masked by taking the gist against
dom_and_slab, which would remove the constraint that n > 0.)

The fix is to teach the code about the actual bounds that get
implemented.