This implements a number of new safety checks and error messages
when object constructors are used:
In case objects:
* the compiler will prevent you from initializing fields in
conflicting branches
* When a field from a particular branch is initialized, the
compiler will demand that the discriminator field is also
supplied with a maching compile-time value
In all objects:
* When the "requiresInit" pragma is applied to a type, all fields
of the type must be initialized when object construction is used.
The code will be simplified in a follow up commit.
The problem comes from the fact that macroOrTmpl[...] is transformed by
semSubscript which is trying to evaluate macroOrTmpl identifier in place. This
is okay for non-generic macros or templates, but wrong for generic ones, that
do not have a chance to receive their generic arguments explicitly specified in
brackets.
Solution:
1. macroOrTmpl[...] where macroOrTmpl is non-generic macro or template, then
macroOrTmpl is evaluated before applying brackets. (as before)
2. macroOrTmpl[...] where macroOrTmpl is generic macro or template, then if:
a. It comes from macroOrTmpl[...](...) call expr (efInCall), then macroOrTmpl
is turned into a symbol (efNoEvaluate) rather than evaluating it in place,
then whole bracket expr is returned to semIndirectOp which transforms it
to proper generic macro or template call with explicit generic arguments.
b. macroOrTmpl[...] does not come from call expr, as above macroOrTmpl is
transformed to symbol, then it is transformed into proper generic macro or
template call with explicit generic arguments and no normal arguments.
