Update .good files to reflect new expected behavior.

Now, default-initialization is expected to call the user-defined default constructor.
Merging ChapelRangeBase.chpl into ChapelRange.chpl

Conflicts:
	test/modules/sungeun/init/printModuleInitOrder.good
Futurize types/records/sungeun/chapelTypes/record_range
Fix some tests in types/records/sungeun

Updated classInRecord.good to match the behavior on the branch.  Examining the source
code, it appears that it is correct for the default-constructor of myR to be called even
when no initializer is provided in the declaration.  That means "c = new myC();" will
always be called when a record is initialized.  Hence, no cases remain where the "c" field
in a myR record can initially be nil.  The revised .good file shows that the "c" field is
now always (correctly) initialized.

Futurized the test case constructor2.  Normalization currently converts declaration
constructs that are intended to represent copy-initialization with default-initialization
followed by assignment.  Details appear in the added .future file.  Fixing the underlying
problem is well beyond the scope of the current effort.
Handle the special case where a generated constructor call involves runtime type arguments

As currently implemented, runtime type handling will not create a SymExpr containing a
TypeSymbol referring to a type flagged with FLAG_HAS_RUNTIME_TYPE into a _RuntimeTypeInfo
instance.  To coerce insertRuntimeInitTemps() into doing its job, I added the function
fixupRuntimeTypeArguments() and call this with the new default constructor call after it
has been inserted into the tree.

For each actual argument that names a runtime type, fixupRuntimeTypeArguments() inserts a
type temp and initializes it through a call to PRIM_INIT (passing that type).  This
provides runtime type handling with AST that conforms to its expectations.
Futurized the two array-of-records-crash-1 test cases, pending in-place initialization.