Make calling user default constructors play nicely with _defaultOf.

This is a temporary solution that allows the properties of _defaultOf and user default
constructor calls to be displayed simultaneously in the compiler, but which does not
reflect the desired solution.

The hack is that the default constructor is called if the default constructor call
resolveds to a call to a user-defined constructor.  Otherwise, _defaultOf() is called.
The desired solution is to call _defaultOf() from *every* constructor (user-defined and
compiler-generated alike) to perform the value-initialization guaranteed by the spec.
Additional semantics in the constructor would take care of setting non-default field
values and establishing class invariants.

The reason why this is not done right away is that significant rework of the constructor
implementation is required to achieve this goal.  That is, it lies well beyond the scope
of the current effort.  The main roadblock is that constructors in the current
implementation return a fully-constructed object (performing allocation as well as
construction), making it difficult to call another constructor (e.g. the "all-fields"
constructor) after _defaultOf has been called.  It would at least simplify the conceptual
model to turn _defaultOf() and constructors in general into methods, to get around this
problem.

Another difficulty is that attempts to update fields within a user-defined constructor are
rejected if the record being initialized is declared as const.  At a minimum, const-ness
checking must be turned off within constructors.  In addition, those updates are currently
treated as assignments.  But this is not consistent with UMM, since it is known in that
situation that the fields constituting the record are uninitialized.

There are a few assumptions related to the current implementation that allow this
combination of user default constructor calls and _defaultOf() calls to work:
 - The code to perform default-initialization is still inserted in a user-defined
 constructor by the normalization change_method_into_constructor().  In a constructor that
 can be invoked  with an empty argument list, this has the same effect as calling
 _defaultOf (except where _defaultOf is overridden).
 - In the absence of a user-defined default constructor, the call to _defaultOf() performs
 the same function as if there had been a call to the compiler-defined default constructor
 instead, and the compiler-defined default constructor was defined as a call to _defaultOf
 followed by an empty constructor body.  By default, the body of the compiler-defined
 default constructor *is* empty, so that behavior is consistent with the desired behavior.

The required changes in this commit were put in conditional compilation clauses to
facilitate design discussions with Lydia.
diff --git a/compiler/include/flags_list.h b/compiler/include/flags_list.h
index 19a77d3..2a10ad5 100644
--- a/compiler/include/flags_list.h
+++ b/compiler/include/flags_list.h
@@ -205,6 +205,9 @@ symbolFlag( FLAG_TYPE_CONSTRUCTOR , npr, "type constructor" , ncm )
 symbolFlag( FLAG_TYPE_VARIABLE , npr, "type variable" , "contains a type instead of a value" )
 symbolFlag( FLAG_USER_NAMED , npr, "user named" , "named by the user" /* so leave it alone */ )
 symbolFlag( FLAG_VIRTUAL , npr, "virtual" , ncm )
+// Used to mark where a compiler generated flag was removed (but is desired
+// elsewhere).
+symbolFlag( FLAG_WAS_COMPILER_GENERATED, npr, "was compiler generated", "used to be marked compiler generated")
 symbolFlag( FLAG_WIDE , npr, "wide" , ncm )
 symbolFlag( FLAG_WIDE_CLASS , npr, "wide class" , ncm )
 symbolFlag( FLAG_WRAPPER , npr, "wrapper" , "wrapper function" )
Pick up remaining test cases in lydia/userDefinedDefaultFunction/

Only 4 of the 9 test cases were being handled correctly, because we key off of whether the
resolved default constructor is compiler-generated, and only replace the default
constructor call with a call to _defaultOf() in that case.
In general, the creation of a wrapper drops the compiler-generated flag, so test cases
involving generic types were failing.  I worked around this by supplying a new flag to
indicate that a default constructor was originally compiler-generated.  We can convert the
default constructor call to a _defaultOf() call if either of the two flags is true.
Fix the two failing test cases infer_field10 and infer_field11.

This change allowed the two cases above to work correctly, using _defaultOf() to provide
the inferred field types.
Minor cleanup.
This permitted the test case test_record_of_array_type3 to succeed.
Fix four test cases failing due to early (double) deletion.

After getting all the userDefinedDefaultFunction test cases working, there were four test
cases failing due to early deallocation errors.  I traced this to the fact that
_defaultOf() acts like a constructor.  So I added it to the set of cases where the return
value should not be auto-destroyed.

I decided against adding a flag to support this, because I expect this particular hack to
be temporary.  When _defaultOf() is a method, it will not behave like a constructor.