Call default constructor by name.

In the compiler-generated _defaultOf() function, set up the call to the zero-args
constructor using its name rather than pre-resolving it to the all-fields constructor.
This will allow binding a user-defined default (zero-args) constructor if there is one.

Also, simplified the logic and flattened the loop structure.
Translate PRIM_INIT to _defaultOf() uniformly.

The existing code determines if there is a user-defined zero-args constructor and uses
that if there is, otherwise uses _defaultOf().

The compiler-supplied version of _defaultOf() now calls the user-defined default
constructor, so the test and extra code can be removed.
Accept improved behavior of explainIntantiation.

Making _defaultOf() call the zero-args constructor by name removed the inexplicable second
call to the range constructor in DefaultRectangularDom (a wrapper, perhaps), and replaced
it with an instantiation of the range type.  The runtime behavior is unaffected.

That instantiation chain seems more logical, so I'm putting this down as an improvement.
Remove generateConcreteConstructorCall() and helpers.

On-the-fly generation of concrete constructor calls is no longer necessary, because the
code that generates _defaultOf() was changed to call the zero-args constructor by name.
Since the insertion of the zero-args constructor call was moved there (buildDefaultArgs),
insertion at resolution time is no longer necessary.  So the above function and its
helpers have become dead code.

Also, I set up some asserts that will permit merging the tails of the two initialization
clauses.
Add pragma "compiler generated" to range.range as a workaround.

After reworking the compiler-generated version of _defaultOf() for a record type so it
calls the no-args constructor by name(!), the single test case
types/records/sungeun/chapelTypes/record_range fails because name lookup during resolution
does not work as specified.

I excerpted the pertinent text from the spec and added this to the test to underscore what
is expected.

I restored the desired behavior for this test case by adding the "compiler generated" flag
to the constructor range.range in ChapelRange.chpl, but this is an ugly hack.  The correct
solution would be to perform name lookup during resolution as required by the spec.
However, that change is likely to be significant, so I left it as a future effort.
Merged identical tails for two cases in resolvePrimInit().

Previously inserted asserts proved that the tail of the case for
  type->defaultValue || type->symbol->hasFlag(FLAG_TUPLE)
and
  type->defaultInitializer
could be merged and moved out to the top level.  So I did that (and removed the asserts).

I proved that the transformation was correct by running the full test suite, tossing both
--no-local and --verify flags.
Convert record_range.chpl into a future.

Since the problem is in the compiler, we shouldn't really compensate in the module code.
I put ChapelRange.chpl back the way it was, so that the error condition is exposed and
then turned record_range.chpl into a future.
Revert the addition of pragma "compiler generated" to the range constructor.
Merge pull request #678 from hildeth/defaultOfDominates

Give _defaultOf() precedence over default constructor calls

In the place where resolution used to call the user-default constructor if it existed and _defaultOf() otherwise, _defaultOf() is now called unconditionally. In the place where the compiler-supplied implementation of _defaultOf() for records used to call the compiler-generated all-fields constructor, it now calls the zero-args constructor by name. Removing the special case for user-defined default constructor calls from resolution allowed a considerable amount of redundant code to be removed.