This commit returns to a bit less strict checking of the number
of macro arguments, because some old immediate macros rely on a
behavior where even the arity of the macro is not being checked.
It may be better if such macros are just declared to use varargs[expr],
but this remains for another day.
Previously it was not possible to use template arguments in template body as
the symbols were not resolved correctly leading to Error: undeclared
identifier: 'XX', eg.:
template defaultOf[T](t: T): expr = (var d: T; d)
echo defaultOf(1) #<- invalid identifier, but should output 0
Since immediate templates are not subjected to the standard sigmatching
algorithm, they will have a number of deficiencies when it comes to generic
params: Type dependencies between the parameters won't be honoured
and the bound generic symbols won't be resolvable within their bodies.
We could try to fix this, but it may be wiser to just deprecate immediate
templates and macros now that we have working untyped parameters.
Disabling the new features is admittedly not the greatest way to handle
this situations as it introduces inconsistency in the language, but at least
it makes the code backwards-compatible with the previous version of the
compiler instead of triggering more serious problems.
Implementation notes:
Just after overload resolution, the resolved generic params will be added to the
call expression to be later processed in evalTemplate and evalMacroCall. These
procs have been modified to handle the increased number of parameters, but one
remaining issue is that immediate templates and macros don't go through the same
process. The next commit will outlaw the use of generic parameters with such macros.
