Fix missing type() dtor call due to addrof/deref optimizations
ast: Let astDtorListFlush() callers do the astNewLINK() with the main tree
ast: Rename astUpdComp2Branch() to astBuildBranch()
Fix bad conditional loop branches if temp var dtors had to be called

astBuildBranch() did not handle isinverse in the code path that handled
turning relational BOPs into branches while having to call destructors
of temp vars from the condition expression. That affected DO UNTIL
and LOOP WHILE where the condition was a relational BOP with temp vars
with dtors.

For example, for this DO UNTIL loop:

	do until foo = bar
		body
	loop

the compiler generated:

	looplabel:
		if( foo = bar ) then goto nextlabel
		dtorcalls( )
		goto exitlabel
	nextlabel:
		dtorcalls( )
		body
		goto looplabel
	exitlabel:

but the conditional branch is wrong, the loop will continue while foo = bar
instead of stopping then. After this patch the compiler produces:
		...
		if( foo <> bar ) then goto nextlabel
		...
instead, meaning the loop will exit if foo = bar.
Fix missing/double temp var dtor calls in iif() conditionals

If an expression uses temp vars, the compiler may have to emit dtor calls
to destroy the temp vars at the "end of the expression", or when the
expression goes out of scope, which in practice means the "end of the
current statement". For conditional branches such as the conditional
expression of IF blocks, WHILE/UNTIL loops or iif()'s this is problematic
though, because the statement is a branch/jump, so the dtor calls must
somehow be inserted right in front of the jump, but still behind the
expression itself, so that the dtor calls happen after the expression is
used, but before the branch. Emitting dtor calls after a jump would of
course mean they'd never be reached.

Before this patch the compiler generated dtor calls behind the conditional
branch, but on both true and false code paths. For example:

	if expression then
		true-block
	else
		false-block
	end if

normally becomes:

	if( expression = FALSE ) then goto elselabel
		true-block
		goto endlabel
	elselabel:
		false-block
	endlabel:

but with dtor calls it became:

		if( expression ) then goto nextlabel
		dtorcalls()
		goto elselabel
	nextlabel:
		dtorcalls()
		true-block
		goto endlabel
	elselabel:
		false-block
	endlabel:

i.e. the conditional branch was inversed, to jump to the true code path,
in order to jump over the dtor calls for the false code path. The dtor
calls for the false code path plus a jump to the false block were added
by astBuildBranch() aswell, using astDtorListFlush( FALSE ). That left
the temp vars registered, so the next astAdd() would pick them up and emit
the dtor calls at the top of the true block. That of course assumed the
next astAdd() was part of the true block.

This apparently worked with IF blocks and loops, however it breaks with
iif(), because with iif() both true/false blocks are part of the same
statement. So the astAdd() was part of a completely unrelated statement,
thus the true dtor calls could end up on both true/false code paths,
resulting in double dtor calls for the false path. (also, if the next
statement was an conditional branch itself the effects could be even worse)

To fix this, this patch changes astBuildBranch() to emit the dtor calls
only once, between the condition expression and the branch, instead of
behind the branch but on both code paths. For the example above, it will
now produce:

		tempvar = expression
		dtorcalls()
		if( tempvar = FALSE ) then goto elselabel
		true-block
		goto endlabel
	elselabel:
		false-block
	endlabel:

I.e. the dtor calls will be emitted only once, but instead a temp var will
be used to hold the condition. This way it won't make assumptions about
the following astAdd() anymore, and work with iif() too.
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.
tests: Add more string iif() -> string parameter tests
doc: wiki backup
Allow iif() on UDTs

Allowing UDTs in the iif() type checks is easy enough, but dealing with
constructors is more complex.

If the UDT has any constructors, iif() must construct its temp var one
way or another (assuming that if there are one or more constructors, one
must be called). Either by constructing it from the true or false
expressions (i.e. in the true/false code paths), or by calling a default
constructor in either one of the code paths. And instead of calling the
default constructor in both code paths, we can emit one call before the
conditional branch to make the generated code smaller.

Constructing the temp var from the true/false expressions is possible if
the given expression is a variable of that UDT type and the UDT has a
copy constructor, or if the given expression is a CTORCALL node, i.e.
a UDT( ctor-parameters... ) or type<UDT>( ctor-parameters... ) kind of
expression. All that actually is handled by astBuildImplicitCtorCallEx()
though, we just need to check the is_ctorcall boolean it returns to see
whether any constructor actually matched and thus could be called,
because if not then we can try to call the default constructor and do
a shallow copy afterwards, or bail out and show an error if that's not
possible (if there is no default constructor, only non-default ctors for
which we don't know the arguments).
Disallow creating objects of abstract class via type()

Only type<>() was checked since 7ce32a19, but the type() check was missing.
Parse type<dtype>() as ctor call even if the dtype has CONST bits

so that type<const UDT>() works just like type<UDT>().
Fix type() and type<>() type checks for built-in types

Even though someinteger = type( 123 ) worked, someprocptr = type( ... )
did not, same for enums, because the old checking code assumed that
if the parser.ctxsym is set, it's the subtype of a struct. But of course
other types such as function pointers and enums use a subtype too, so
that assumption wasn't right.

(see also: 5fa418b5f0c2ddad955a386671da1aca00fb92c6)
symb: Change typeDump() to print out CONST bits too
Disallow parameter initializers for BYREF AS ANY|FWDREF parameters