astDtorListFlush(): Remove now unused del_nodes parameter
ast: Ensure to always update the TYPEINI counter in astCloneTree()

When cloning TYPEINI nodes, the counter must be updated, or else
astTypeIniUpdate() won't resolve them.
Fix bad temp var dtor calls for the unreached expression in an iif()

Temp vars used by the true-expression or the false-expression in an iif()
will only be constructed when their expression is executed. Since the whole
point of iif() is execute only one of the two, we cannot just destruct
all temp vars at the end of the whole expression that included the iif().

Instead, essentially we must destruct only the temp vars that were
constructed, i.e. whose code path was chosen in the iif(). The easiest
way to do this is to emit the dtor calls for these temp vars right into
the iif()'s true or false code paths respectively.

Another way to do this would be emit a boolean "is_constructed" flag for
each temp var (could be done in form of an integer temp var, or even bit
flags to avoid having to allocate tons of flag temp vars if there are lots
of temp vars that need destructing).

On the other hand, saying that each temp var will always be constructed
(so that we could always safely & easily destruct it) would be wrong,
because expressions that are not reached in an iif() should not be
executed, not even temp var ctor calls.

Thus, it seems like the first solution (emitting the dtor calls into the
true/false code paths of the iif()) is the best way to go. It would be
risky to do this if the temp vars from the true/false expressions could
be used/referenced outside the iif() somehow, but currently I can't see
that happening ever, especially since iif() uses a temp var itself to
store the result. As long as we emit the dtor calls behind the assignments
to the iif temp var, it should be safe.

Of course all this also affects the ANDALSO/ORELSE short-circuiting
operators since their second operator can also be an unreachable
expression. Thankfully they are implemented using iif() internally,
so fixing them too is easy.
ast: Leave TEMP flag on IIF() temp strings, and use astDtorListAdd()

instead of the symbUnsetIsTemp() and astAdd( astNewDECL( ... ) ) hack,
that essentially makes the temp string a local var in the current context.

We should never astAdd() something during the expression parsing though,
everything should be contained in the expression tree itself instead.

This allows a string iif() to be used in string parameter initializers
(and most likely also field initializers). Since iif() won't effectively
turn the string temp var into a local var (non-TEMP and with DECL node),
the astTypeIniUsesLocals() checks won't complain anymore.
ast: Ensure to not leave a dangling pointer when cloning TYPEINIs
ast: Solve out unnecessary wrapper TYPEINIs from param initializers

1) to avoid trying to create z/wstring temp vars during astTypeIniUpdate()
when the parameter was BYREF AS Z/WSTRING.

2) to avoid unnecessary temp var copies due to the extra TYPEINIs
   This is due to the use of cInitializer() to encapsulate the initializer
   expressions in a TYPEINI. In FB 0.24 this only affected UDT parameters,
   but since 82966181 this affected all types of parameters.
Fix passing of [W]STRING iif()'s to BYREF AS Z/WSTRING parameters

Instead of returning the VAR access on the iif() temp var from astLoadIIF()
as a hack, the IIF() will now contain the VAR access from the beginning,
and astSetType() will propagate any type changes (from optimizations)
up to the IIF's VAR access.

I believe this means that IIF nodes behave exactly like VAR nodes as far
as emitting is concerned, although things like taking the address of an
iif() as in <print @iif(...)> will still not work.

Also, in astOptAssignment() IIF nodes are now handled like FIELD nodes,
so that string assignments from iif() still work ok.