Fix #670: Allow Byref functions to return array param elements
parser: Fix mid() statement to allow all kinds of destination expressions

This patch simply removes the symbol checking code from cMidStmt(),
effectively allowing expressions without attached symbols. I have no idea
why it was there in the first place, except perhaps to match QB behaviour.

The CONST check could be simplified to an astIsConstant() too.
crt/limits.bi: Fix UINT_MAX (closes #664)
crt/limits.bi: Add FLT_MAX and DBL_MAX #defines (also for #664)
pp: Show error for invalid #define id, instead of just ignoring the #define
ppDefine(): Turn into a sub, function result unused
symb: Increase FBSYMCHAIN pool size (fixes #686)
todo.txt: Add note about FBSYMCHAIN allocation issue
Add test case and changelog entry for #686
Add more informative messages when vararg param '...' is misused, either as the first parameter or in a non-cdecl function.
(Potentially, we could also set the compiler to default to cdecl for vararg parameters.)
Disallow passing integers to BYREF Z/WSTRING params without explicit BYVAL

Given a procedure like this:
	declare sub f overload( byref as zstring )

the compiler allowed both of:
	f( 0 )
	f( byval 0 )

which worked the same, but it seems like the first case was only allowed
by accident.

Conflicts:
	changelog.txt
Overload resolution: Refuse z/wstring <-> integer, unless it's a DEREF

z/wstring belong to FB_DATACLASS_INTEGER, and indeed they can be treated
as integers (hence char/wchar), but only if it's a DEREF expression.
In other cases (z/wstring variables or literals) the compiler refuses
treating them as integers, and only allows them to be treated as strings.

This patch adjusts hCalcTypesDiff() to follow those rules more closely,
or so I hope.

- Disallow integer (non-z/wstring) arg to z/wstring param
- Only allow z/wstring arg to integer param if it's a DEREF
- Allow string arg to z/wstring param
Overload resolution: Don't calculate optional params into match score

(fixes #603)

This patch changes symbFindClosestOvlProc() to stop treating optional
parameters for which no args were provided as "full matches". I think it
makes more sense to score overloads only based on the given args, and
default args inserted for optional parameters shouldn't artifically push
an overload's score up.

It's an attempt to replace the "normalization" code added in bae05570
with a better solution, because the "matches /= total_args" division
is prone to rounding errors which can falsify the matching scores.

For example:
	declare sub f overload( ul as ulong, i as long )
	declare sub f overload( ull as ulongint, i as long )
	dim as byte b
	f( b, 1 )
The 1st overload scores matches=41, the 2nd matches=39. After the divison,
both have matches=20 though due to rounding, making them appear equal even
though the 1st one was originally better than the 2nd one.

Another example where it happens to work ok:
	declare sub f overload( ul as ulong, i as integer )
	declare sub f overload( ull as ulongint, i as integer )
	dim as byte b
	f( b, 1 )
The 1st overload scores matches=68, the 2nd matches=66. After the divison,
the 1st has matches=34 and the 2nd matches=33. Here the 1st one still is
better than the 2nd, so it doesn't make a difference.

Besides, it seems to me like the normalization code was only added to
work-around hCalcTypesDiff()'s problems with z/wstring params/args, judging
from the regression test added in bae05570. That problem should be fixed
now since the previous commit (2f9ea994) though, and now it should be
possible to remove the normalization code.

To change the behaviour, this patch
- removes the "matches += FB_OVLPROC_FULLMATCH" line from the optional
  parameter code path
- introduces a new local "is_match" variable, to be relied on instead of
  checking "matches = 0", because now that optional parameters no longer
  increase the "matches", a zero value in "matches" can be a valid match
  (in case of zero args given, matching an overload which has only optional
  parameters)
Overload resolution: Don't prefer paramless overload if zero args given

For example:

	declare f overload( )
	declare f overload( as integer = 0 )
	f( )  '' ambigious call

To be consistent, this should be an ambigious call, same as this:

	declare f overload( as integer )
	declare f overload( as integer, as integer = 0 )
	f( 0 )  '' ambigious call

C++ also behaves this way.

This change broke (or from my point of view: "exposed bugs in") some test
cases so I had to remove those. They had two default constructors, one
with zero parameters, one with an optional parameter - that should never
have been allowed, the compiler can't know which one to call. As in C++,
this is an "ambigious call" error now.
Merge branch 'master' into 64bit
ast: Disable constant conversin overflow warnings during optimizations

Thanks to the changes from the 64bit branch, even optimizations use the
AST's constant folding to evaluate everything, and the AST was also changed
to check for overflows in constant operations more precisely. This lead
to it reporting warnings for code that looks ok, due to expressions being
changed by optimizations.

For example:
	dim as uinteger ui
	print ui - &hD800 - &hDC00
was "optimized" to:
	dim as uinteger ui
	print ui + 4294912000 + 4294910976
and then the constant accumulation optimizations caused the overflow
warning when trying to add those two huge values together.

It's worth noting that normal fbc (without the changes from 64bit branch)
doesn't show a warning when compiling either of the two snippets above,
while the new fbc from the 64bit branch would show a warning in both cases.

This patch adds a boolean to the AST context, allowing astOptimizeTree()
to temporarily disable the overflow warnings, so it can use astNewBOP()
etc. without worrying. This matches the idea of only showing warnings for
the user's code, but not for any internal expression restructurings etc.
astCheckConst(): Remove x86/32bit comment, I think it's no longer true
ast: Add common function for CONST evaluation result truncation
ast: Also disable conv overflow warnings for CONST eval result truncation

There were additional warnings appearing now because the AST does the
internal calculations at 64bit precision instead of 32bit, so it started
detecting 32bit overflows even on 32bit. To match the old behaviour, this
patch disables that.

Effectively, now warnings should only be shown during casts, assignments
or argument passing, but not for the result of math operations. BOPs etc.
will always promote operands to INTEGERs now anyways.

And I also think that it's ok to hide overflow warnings for the native
integer size even though the compiler may be able to detect them.