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
OpenGL NeHe examples: Rename uses of 'object'/'OBJECT' (now a keyword)
Glade examples: rename references to 'object'; conditonal NULL definition in glade_gui.bas
Glade headers: replace references to "gtk/gtk____.bi" to "gtk/gtk.bi" (individual gtk files no longer in repository; removed in 03d7433)
parser: Show warning for calls to BYREF function with '=' in 1st arg
parser: Allow '=>' as assignment token as less ambigious alternative to '='
parser: Also check overloads for the '='/BYREF function warning
Add mode parameter to Lcase()/Ucase(), mode = 1 = ASCII only
Add compile-time evaluation for Lcase/Ucase ASCII-only mode
rtlib: Move old lcase/ucase functions into legacy modules

The old lcase/ucase functions without mode parameter aren't used by
the compiler anymore now, but we should still keep them in
libfb[mt].a for backwards compatibility with FB 0.24.
objinfo reader: Re-add support for old (<= 0.24) format

for better backwards compatibility. See also b4987489.
L/Ubound: Return 0/-1 instead of 1/0 for out-of-bounds dimension

In 9a9b1108, Lbound/Ubound were changed to return 1 or 0 respectively if
the dimension parameter was out-of-bounds and <> 0 (dimension = 0 returns
the array's dimTB lbound/ubound).

However, this breaks existing is-array-empty checks like:

	@array(lbound(array)) = NULL

and in order to keep these working it's better to use lbound=0 ubound=-1.

See also: <http://www.freebasic.net/forum/viewtopic.php?p=186857#p186857>