Fix temp var destruction in local array initializers

http://www.freebasic.net/forum/viewtopic.php?f=3&t=22753
parser: Don't abort when warning about mismatching parameter initializers

Since the "mismatching parameter initializers" warning was added in
301962fc, it also caused hCheckPrototype() to abort, which caused
cProcHeader() to do "return CREATEFAKE( )" which it normally only does
for error recovery.

1. This should just be warning though, not an error.
2. The symbol created by CREATEFAKE() is not completely the same as what
would be produced in the absence of errors; for example it will use a
temporary identifier instead of the original. Because of this, the newly
added "warning" could even cause procedure bodies to be emitted under an
incorrect name, resulting in linker errors.
parser: Improve hCheckPrototype() error recovery

There's no need to abort cProcDecl() just because hCheckPrototype()
detected mismatches, and also there's no need to abort hCheckPrototype()
early in case it finds something. The parser should just continue, for
better error recovery.
overload resolution: Ingore CONSTness for RTL procedures without RTL_CONST

(closes #735)

This is a regression from 8d8df7ad. Before that commit, the code contained
two calls to symbCheckConstAssign(), the first guarded by a
	if( typeGetConstMask( param_dtype ) ) then
and the second guarded by
	if( (symbGetIsRTL( parent ) = FALSE) or (symbGetIsRTLConst( param )) ) then
Given that none of the RTL functions had CONSTs on their parameters,
all were redirected to the second check, causing them to be handled
correctly. The commit changed the code though, such that the first call
to symbCheckConstAssign() was no longer guarded this way.
hCalcTypesDiff(): Fix comment typo
overload resolution: Combine and fix redundant CONSTness checks

(closes #728)

1. The first symbCheckConstAssign() did not consider parameter mode

2. The entire code path/logic seemed weird/wrong - e.g. two calls to
symbCheckConstAssign(), one outside the "type_is_compatible" guard.

This already doesn't make sense as it would allow incompatible types to
match during overload resolution if they match based on CONSTness alone.

Also, the part of code using const_matches for the second
symbCheckConstAssign() call does not make sense, as it can never be reached
if the types are compatible, because then the first constness check will
already have determined the match. Thus for now that is removed too, though
I think it can be fixed in the future.
symbDump(): Default to not showing parameters

(it's not always needed, and it's annoyingly huge output)
Implement implicit UDT members after calculating UDT return type

This fixes an issue where the implementation of implicit UDT members
(specifically, building the vtable) wanted to use the UDT return type
(due to a virtual method with byval self function result), but could not
because it was not known yet (it triggered the assert() in
symbProcRecalcRealType() when creating the function pointer for the
vtable slot).

This is a regression from 8b5db5c1 where the order of
adding the implicits and calculating the UDT return type was changed.

The solution to fix both cases (the original issue from the old commit,
and the regression introduced by the old fix) is to split declaration from
implementation of implicit members, and calculate the UDT return type in
between.
Fix #737: Remove ImageInfo() LongInt overload, use Integer version only

This partially reverts 6c13fc0c. It's the same problem as with
ScreenInfo() (57335003) and GetJoyStick() (87b1c3fe): In a call such as
	ImageInfo image, , , , , pixdata
the compiler cannot decide whether to use the Long or LongInt overload
because none of the integer parameters are given.

To allow such calls to keep working, there can only be one version of
ImageInfo(). As with the other cases it seems best to choose a version
with Integer parameters. Besides being FB's default data type, it will
accept Longs/Integers on 32bit (as always) and LongInts/Integers on 64bit.
That's not perfect as existing code using Longs on 32bit won't compile for
64bit, it must be changed to use Integers first, but this is acceptable.
ARM: Use 8-byte alignment for DOUBLE/LONGINT

According to the ARM ABI and Ubuntu's arm-linux-gnueabihf-gcc, double and
long long (LONGINT) are 8-byte aligned, as on Win32, unlike 32bit x86
Linux.

Relevant ARM ABI document:
Procedure Call Standard for the ARM Architecture (AAPCS)
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0042e/index.html
makefile: Normalize TARGET_ARCH to "x86_64" in case it was set to "amd64"
Fix lset/rset when the rhs was an empty var-len string (was mistakenly aborting when src->data == NULL), when an empty string should actually result in a destination full of spaces.
ASM backend: Correctly extract LONGINT low/high dwords on 64bit
Default to -gen gas when cross-compiling to 32bit x86

Previously, fbc would default to -gen gcc when cross-compiling to 32bit x86
on a 64bit x86_64 system, because -gen gcc is the default for 64bit.
ast.bi: Remove dead hTruncateInt() declaration
ASM backend: Adjust emitVARINIi()'s value parameter to be a LONGINT

This way the str() it does will be a str(longint) instead of a
str(integer), i.e. it will produce the same output no matter whether
on 32bit or 64bit. E.g. &hFFFFFFFF in variable initializers will now
always be emitted as 4294967295 instead of -1 (with 32bit signed Integer)
or 4294967295 (with 64bit signed Integer).

This matches the other code dealing with raw values (e.g. FBVALUE or
IR's _emitVarIniI()).
ASM backend: Combine emitVARINIi() and emitVARINI64()

Now it matches the IR interface which also only has a single emitVarIniI()
callback.
Combine symbAllocIntConst() and symbAllocLongIntConst() in similar way

The two were exactly the same except for the value parameter type which is
only used as input to the hex() call, resulting in hex(longint) in
symbAllocLongIntConst() (intended for 64bit values) and hex(integer) in
symbAllocIntConst() (intended for 32bit values).

Not only is that duplicate code, using Integer for 32bit is also suboptimal
since it changes to 64bit on 64bit. So now the combined function uses
hex(longint) and hex(long) for 64bit/32bit values respectively.
ASM backend: Don't allocate stack space for fake dynamic array symbols

Fixed: #739

Only the array descriptors should be allocated on stack, not the internal
dynamic array symbols. The C/LLVM backends already do this correctly.

The ASM backend though reserved extra memory based on the dynamic array
symbol's FBSYMBOL.lgt field, which is set to the size of the array element
data type by symbAddVar(). This memory was never used though, since the
array descriptor was still allocated separately, and all accesses to the
array go through the descriptor anyways. In the worst case it could cause
a stack overflow.
install.sh: Copy lib/freebasic/ recursively

For FB 0.90.1 copying lib/freebasic/ non-recursively was enough, but now
that there can be lib/freebasic/linux/ or lib/freebasic/x86_64-linux/ etc.
subdirectories again, we need to copy recursively, and it should work no
matter what name the lib/freebasic/<target> directory has.