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.