Allow noinit on records and classes (but not dists/arrays/domains/syncs/singles) [reviewed by Sung]

Making use of the defaultTypeConstructor for a class or record allows for
construction of an instance without initialization of the particular fields 
that would make it a complete instantiation of the type.  This was the
brainflash I was missing when originally implementing noinit.  The type
constructor makes use of the param and type arguments necessary for determining
the space of the type while leaving the initialization of the remaining
arguments to the default initializer.  It thus makes sense that noinit would
"call" this method (type constructor calls are removed at the end of function
resolution, so they are "called" by the compiler but don't turn up in the
generated C code).

Dists, domains, arrays, syncs, and singles are more complicated than the base
class/record situation and so are not solved by this simple solution -
domains, for instance, access the inner fields of their _value field during
assignment and we do not currently have a way to check if that field has been
initialized yet (for noinit, it has not).  This field cannot be assigned to
at the moment: there is an getter-only override and no corresponding setter
due to the potential privitization of the type.  Dists and arrays are in a
similar situation: their _value field also has a getter-only override.  My
suspicion is that syncs and singles will need to have their write** methods
adjusted for the possibility of an uninitialized value field.  Until these
problems are solved, these types will continue to be barred from using noinit.

This commit also removes the futures from 7 noinit tests, all involving classes
and records, as they should work now.

tested over std/


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@23858 3a8e244f-b0f2-452b-bcba-4c88e055c3ca