AST generator: improve handling of pending constraints

AST generator: improve handling of pending constraints

While generating an AST we may come across constraints that are not
directly encoded in the AST, but that are still exploited to simplify
other constraints.  In the downward pass of the schedule, these constraints
are stored in the pending constraints of the build.  In the subsequent
upward pass, they are moved to the guard of the graft and hoisted up
as far as possible.

Once we have decided that a guard will be generated, we need to make
sure that it will actually be generated since we may have used it to
simplify some other constraints.  We were not always that careful
about these constraints in the original code.  In particular, after
deciding to introduce a guard, we might still simplify it away
in the context of the enforced constraints of the graft or
in the context of the pending constraints of an outer build.
This probably did not cause any problems in practice, because
the constraint does end up getting enforced somewhere.
However, in principle, it could happen that two constraints
end up getting simplified with respect to each other and then
the result might be wrong.
Moreover, if we ever want to determine the required size for iterators,
then we need to make sure that the constraints we use for these
measurements are enforced before reaching the code where
the measurements take place.

In fact, the main problem with the original code was that it was
not clear when we actually decided which constraints to generate
as guards, with parts of the implementation using the build "domain",
whereas they may have to use only the generated constraints of the build.

In this commit, we make this decision more transparent and more local.
Once we have decided which constraints to
generate as guards, we add them as guard to the graft and make sure
that they will be generated by outer constructs.  The if conditions
and for loop bounds generated within that context can then freely
exploit these constraints.  We enable this by adding these constraints
to the generated constraints of the build where these constructs
are created, while completely removing the pending constraints
such that there is no longer any confusion between "domain" constraints
and generated constraints.
The determination of which constraints to add as guards is then
the only part that still needs to make this distinction.

The extra constraint that gets added to separate2.c by this commit
is caused by an issue in the gist operation that will be handled
in a future commit.

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