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.