In Handle_Filter, we were switching non Match_None match modes to
Match_Has, while forgetting to keep the previous value otherwise, resulting
in uninitialized data. Now fixed.
In Push_Call_Result of a W_Function, the iteration decision was dismissed
and not transmitted to the parent frame. Moved the transmission after
poping the calling frame.
Tests and fixes TA02-001.
One of these cleanup turned out to be the behavior of allocators in the
context of calls that are generating all values, e.g. in:
child (new (something ())).all ()
Turns out there's no reason to forbid this, the natural semantic is that a
new object will be created for all child of the current it.
Writing a node kind predicate of e.g. the form Entity (<some expression>) used
to push an instrinsic call if "Entity" matched the kind of the langkit node,
said call checking the expression. The confusing consequence is that, even
if something like "match Entity" could match, it was stack a call and not
the value of the object, while "match Entity ()" would execute the call
and return the value. It turns out that entities already provide ways
to check their value against an expression, so stacking the object instead
of an instrinsic call already works for both cases.
