gfxlib2: Fix read-after-free in X11 OpenGL driver_init()

XFree(info) shouldn't be called before the fb_hX11Init() call which
accesses info->depth in its argument list.
gfxlib2: Check glXCreateContext() result with != 0 instead of > 0

According to man pages found on the web, glXCreateContext() returns NULL
on failure. Also, the GLXContext it returns is a pointer type. Thus != 0
should be better than > 0, and casting to intptr_t and then comparing > 0
especially seems weird since that could cause non-NULL values to be
rejected because they appear to be < 0 (address values > 2GiB wrapping
around/overflowing).
gfxlib2: Don't bother calling glXDestroyContext() on NULL context
libpng example: Don't return from error callback
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.
headers: Update crt/linux/fcntl.bi

mostly to fix wrong #defines, but this update also adds various structures
and function declarations found in glibc's fcntl.h and bits/fcntl.h.
symb: Extend symbDump() to show stats too
symb: Add symbDumpNamespace() for debugging
symbDelSymbolTb(): Ensure to remove all symbols from hashtb, not just some

symbDelSymbolTb() in "hashonly" mode didn't remove all symbols from the
hashtb: it checked for VAR, CONST, STRUCT, etc. but missed at least PROC
symbols (used for function pointer types) that can appear in scopes since
d2ed5a20 (I think).

Given code like this:

	private sub sub1()
		dim subptr1 as sub( )
	end sub

	private sub sub2()
		dim subptr2 as sub( )
	end sub

	sub1()
	sub2()

The AST will not emit the procedures immediately, since they're PRIVATE.
Instead it waits until parsing is finished and then emits the ones that
were used.

When done parsing sub1(), it will not fully delete its symbol table,
only remove the symbols from the hash table (the current namespace) via
symbDelSymbolTb() with hashonly=TRUE. This way, the symbols cannot be
seen anymore, but still exist, which is necessary until sub1() is emitted
later, or else there would be lots of dangling FBSYMBOL pointers.

However, symbDelSymbolTb() missed PROC symbols, causing the PROC symbol
that represented the subtype of the subptr1 function pointer to remain
visible in the current namespace.

Now, when parsing sub2(), this resulted in symbAddProcPtr() re-using the
procptr from sub1() to represent the subtype for the subptr2 function
pointer in sub2(), since both happen to have the same internal name
mangling.

Since sub2() is also PRIVATE, its emitting is also delayed until later.
Finally, when parsing is done and the AST emits the used PRIVATE
procedures, sub1() happened to be emitted first. Afterwards its symbol
table will finally be deleted completely, causing sub2()'s reference to
the PROC symbol from sub1() to become a dangling pointer.
symb: Rework how SHARED/LOCAL attributes are given to PROC symbols

All PROCs representing procedures should be SHARED. They can never be
LOCAL since procedures nested inside scopes aren't allowed.

However, PROCs representing procptr types can be either LOCAL or SHARED,
depending on whether they're added to current scope or to the global
namespace.

In order to handle this nicely, hSetupProc() shouldn't be the one setting
the attributes -- it should be done before hSetupProc().
C backend: Fix string literal initializer emitting (db76b3ea regression)
tests: Allow warnings tests makefile to work with -gen gcc
tests: Add more test cases for 22a858c6

taken from:
	http://www.freebasic.net/forum/viewtopic.php?p=187232#p187232
parser: Improve error message for RETURN vs. FUNCTION=/EXIT FUNCTION