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 dest->data == NULL), when an empty string should actually result in a destination full of spaces.