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.
#736: Fix format overflow when significand (after dividing down to 19 digits) is 2^63 or greater
Test cases added: large fixed-point number (20 digits for brevity), tiny floating-point (only works up to 18 fixed digits)
Fix Format() overflow on very small numbers, trying to scale them by excessively large powers of 10.
pow( 10.0, -ExpValue ) overflows a double if -ExpValue exceeds 308.
Instead, multiply by pow( 5.0, -ExpValue ) and pow( 2.0, -ExpValue ).
The former is safe as long as -Expvalue <= 441.
Test cases added.