Move all the lib build scripts into a common directory
symbPreAddProc(): Clear more fields to prevent uninitialized accesses

The current code that uses symbPreAddProc() should be safe without this,
but this greatly helps when debugging symbols via symbTrace(), plus it's
just safer overall.
cTypeOf(): Fix dangling FBSYMBOL pointer

The astTempScopeBegin/End() code in cTypeOf() was intended to capture
temporary variables created while parsing the first operand of a typeof(),
in case it was a expression such as iif(). These temp var(s) were supposed
to be deleted -- afterall they will be unused anyways, as typeof()'s
operand is never emitted anyways.

However, this temporary scope also captured any other symbols, even when
the typeof() operand was a type (not an expression). Specifically, the
symbol returned as the subtype could be captured in the temporary scope,
in case the subtype symbol was newly created while parsing the typeof()
operand. cSymbolType() will sometimes create new symbols, especially for
function pointers.

Before cTypeOf() returns, it will do astTempScopeDelete(), which deletes
all symbols in the temporary scope. This could cause the subtype to
become a dangling pointer.

I noticed this problem while trying to implement support for
typeof( sub() ) or typeof( function() as integer ). Here cSymbolType()
will use symbAddProcPtr() to add a new PROC symbol to represent the
function pointer. It was captured in the temporary scope and deleted,
causing cTypeOf() to return a dangling pointer in the subtype which caused
strange behaviour in other parts of the compiler (false-positive warnings,
assert()ions triggered).

This problem was introduced with b5129f76 with the intention of
	1) removing dtor calls to temp vars for typeof/sizeof expressions
	2) completely deleting these temp vars, i.e. not emitting them
	   at all, which would just waste stack space

Then, 365c6d2b revisited the issue and adjusted the AST to handle the
dtor call problem in a different way. Apparently I forgot about point 2)
when working on 365c6d2b, because for some reason, it removes the
astTempScopeBegin/End() code from hLenSizeof() but not from cTypeOf().
That means temp vars in the sizeof() operand are emitted again, only the
dtor calls are still avoided.

For now (right before the 0.90.0 release), it seems best to remove the
temp scope stuff from cTypeOf() aswell, such that the problems due to
symbol deletions are gone for now, but at least the compiler still won't
generate dtor calls for any temp vars from the typeof() operand.

Of course the changelog entry must be adjusted a little to reflect this
partial patch reversal. Perhaps in the future a better mechanism could
be added to deal with those temp vars from expressions that will never
be emitted.

(Maybe the AST dtorlist could be extended to be a templist that not only
manages the dtor calls, but actually also the deletion of temp vars.)

For now, it's good enough that no dtor calls will be emitted for such temp
vars, that way they are emitted but unused, i.e. there's no bad code,
only unnecessary stack usage.
parser: Allow TYPEOF() on SUB|FUNCTION(...)

This extends the TYPEOF() type vs. expression ambiguation to recognize
SUB|FUNCTION followed by '(' as type, just as was already done for TYPEOF
followed by '('.

There should be no breakage due to this change, since it's not allowed to
declare any "toplevel" functions/macros/arrays named SUB or FUNCTION.
Only fields in non-class UDTs can be named SUB|FUNCTION|TYPEOF, but those
would have a 'myudt.' or at least an '.' preceding them, which would be
enough to prevent cTypeOrExpression() from treating it as type.

This could be useful to declare pointers to function pointers directly,
without the help of an intermediate typedef:

	dim pp as typeof( function() as integer ) ptr

is the same as

	type myFuncPtr as function() as integer
	dim pp as myFuncPtr ptr

in any case, it cannot be written as

	dim pp as function() as integer ptr

because then the PTR would be treated as part of the function result type,
i.e. it would be a function pointer returning an integer pointer, not a
pointer to a function pointer returning an integer.