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