emit_x86.bas: Use typeGetSize() instead of typeMax()
tests: Add BOP result type test case
BOPs: Treat unsigned types as "more precise", prefer them as result type

This allows INTEGER + UINTEGER to return a UINTEGER just like
UINTEGER + INTEGER. Same for other integer types.
UOPs/BOPs: Convert enums to integers, since the result can be any integer
Fix #661: Pass -m32 to gcc and -march=x86 to llc for 32bit -gen gcc/llvm
C backend: Add explicit "signed" on the typedefs for signed types
Fix #662: C backend: Ensure to emit zstring/fixstr as ubyte
Fix #641: ast: Don't ignore casts that add/remove CONSTs
symb: Also update a proc's real dtype when back-patching forward refs

When replacing the FWDREF dtype on a symbol with the real dtype (when the
forward reference is "implemented"), it's important to update any data that
depends on the symbol's type, such as the FBSYMBOL.lgt length field,
and for procedures, the FBSYMBOL.proc.realdtype/realsubtype fields.

The real dtype fields on procedure symbols were not updated yet, this patch
fixes that. Normally function results cannot be forward references, but
this has changed now that BYREF results are supported.
Fix #657: Allow BYREF AS FWDREF results in function prototypes

(afterall, BYREF parameters allow this too, and also only in prototypes)
astBuildByrefResultDeref(): Improve error recovery
Fix #647: Don't ignore initree for shared/static UDT vars with dtor only
Fix various parameter cycling loops that could break with PASCAL procedures

closes: #621

For the PASCAL calling convention, arguments are pushed in the declaration
order, not reversed like CDECL/STDCALL. This affects the order of ARG
nodes in CALLs, and it affects the C/LLVM backends' code generation,
but that's it.

It should affect neither the parsing of argument lists nor overload checks
on the FB side. However exactly that was happening due to mis-use of the
symbGetProcLastParam() and symbGetProcPrevParam() macros, which would walk
from head to tail through the next links for CDECL/STDCALL procedures,
but walked from tail to head through the prev links for PASCAL procedures,
thus breaking any code that checked the arg being parsed against the param.

For example, cProcArgList() (and also hOvlProcArgList()) use the param
to check for BYDESC:

	declare sub f pascal( a as integer, b() as integer )

	dim array() as integer
	f( 123, array() )

Since "f" is PASCAL here, the parameter list was walked in the wrong order,
causing cProcArgList() to see the 1st arg "123" as param "b", and the
2nd arg "array()" as param "a". Since param "a" isn't BYDESC, the bydesc
array parentheses were disallowed, causing the issue seen in bug #621.

At least astNewARG() would later detect any type mismatches (including
passing "123" to bydesc array param "b", so this also results in a compiler
error:

	f( array(), 123 )

The same problem existed in symbFindClosestOvlProc() which prevented
PASCAL proc overloading from working properly.

Additionally astReplaceARG() (now renamed to astReplaceInstanceArg()) also
didn't handle PASCAL properly, causing it to replace the wrong ARG.
pp: Re-add support for undeclared identifiers in #if expressions

because C also supports it (although with different semantics), so it
seems better to keep this feature.
Add #ASSERT preprocessor statement
- Add [U]INTEGER<n> support for n-bit integers (where n is 8/16/32/64)
- Update LEN/SIZEOF/TYPEOF parser disambiguation to allow treating 'a < ...' as a possible type
- Internal: rename eqinparenTsonly to eqinparensonly to make clear it's talking about parentheses not parents.
- Update parser to remove eq|gtinparensonly inside paren expressions
- Add parser check in lexer to disable '>=' lexing when gtinparensonly is enabled
typeDump(): Print UDT identifier if possible
C backend: Overhaul string literal emitting, now similar to LLVM backend

This changes ir-hlc.bas to emit string literals based on the result of
hUnescape[W]() like ir-llvm.bas instead of emitting directly from the
internal format.

For now this is probably a bit slower, but much easier to understand.
This also fixes a bug where backslashes weren't escaped when emitting
wstring literals. (that probably was a fault in hEscapeToHexW() which is
completely removed by this patch)

In the future the internal escape format should perhaps be removed
completely, letting the lexer handle everything as soon as possible; only
null chars (e.g. from \0 sequences) actually need to be encoded specially
for internal use.

Also, this patch changes ir-hlc.bas to emit global wstring initializers
in form of individual chars ({ L'a', L'b' } instead of L"ab") to work
around the issue of GCC using signed int for wchar_t, while FB uses
UINTEGER, since GCC would show an error for code like:
	unsigned int w[] = L"...";
It just seems safer to immediately use the data type that we expect to be
used, not something else. Signedness can matter, as was seen in 0cd672f.
Merge commit '0cd672f681e8f4f70b87e095d29c8178da11892d' into op-types

Conflicts:
	changelog.txt
UOPs/BOPs: Promote operands to INTEGER (but not under -lang qb)