Don't add implicit ctor/dtor for .con/destructor( ) method call

This reverts c5892a9419ad20d3cfccebb5512283defa94eac3 and closes #3524323.

Adding a constructor or destructor to an UDT after the TYPE ... END TYPE
was parsed is not safe because the compiler only does a single pass.

It might work in practice because it won't matter whether the implicitly
added ctor/dtor is getting called or not, but it can confuse many parts
of the compiler or create "impossible" situations, where first there was
no ctor, and then all of sudden there is one, even though it's still the
same UDT.

For example: It's not allowed to have a field named "constructor" in
an UDT that has methods. However, by using a ".constructor( )" method call
a constructor could still be added. Now, it's no longer clear whether
".constructor" refers to the field or the constructor.

As seen with bug #3524323, the compiler apparently cannot handle creating
methods for an UDT while parsing inside a method of the UDT. It is probably
based around the assumption that method bodies can only be defined outside
TYPE ... END TYPE, and no new methods will be declared after that, or
perhaps it's just that procedure nesting isn't handled well (except for
switching back and forth between the implicit main() proc and the others).
Either way, if ".constructor( )" doesn't auto-create constructors anymore,
then the condition for the compiler crash is gone.
symb: Remove HasC/Dtor stats, use symbGetCompC/Dtor functions instead
symb: Add type/symbHasC/Dtor() functions for easier c/dtor checks
Show "branch crossing" error for UDT vars even with non-default ctors only
parser: Disallow EXIT FUNCTION after RETURN with complex UDT result

This patch makes EXIT FUNCTION have properties similar to FUNCTION=.

For a function with a complex UDT result (i.e. an UDT with a constructor),
the result must be constructed at some point, before returning.

For FUNCTION=, this is done at the top of the function, in preparation for
the FUNCTION= statements that are coming.

RETURN on the other hand uses the copy-constructor to construct the result
right in place of each RETURN statement, like C++.

These two methods are not compatible to each other, and thus FUNCTION=
and RETURN are not allowed to be used together in functions returning
an UDT with a constructor.

This patch makes EXIT FUNCTION trigger the same behaviour that FUNCTION=
triggers, i.e. constructing the result at the top of the function.
EXIT FUNCTION will now be disallowed in combination with RETURN in such
functinos. This fixes the issues of EXIT FUNCTION leaving the result
unconstructed in "RETURN" functions, and also disallows RETURN after
an EXIT FUNCTION was seen.
Call function result ctor even if no result explicitly given

This fixes the issue where the function result was left unconstructed
if the function contained neither FUNCTION= nor RETURN. We'll show a
"function result not explicitly set" warning in that case, but leaving
the result unconstructed must be an error, especially because the caller
is going to call the result's destructor.
Show error when result cannot be auto-constructed for FUNCTION=
Fix imagecreate() param types (caused overflow warning since ed27b50c)