Fix errors involving --no-remove-copy-calls and partially defined extern structs

Previously, if an extern type was partially defined in Chapel code, the
remaining fields would lose their values in certain circumstances (namely when
an initCopy was used).  The initCopy would take in an instance of that record,
copy the fields whose existance it understood, and then pass in an uninitialized
instance of the type to the constructor.  To preserve the values Chapel did not
understand, the argument to initCopy must be passed along to the constructor.
Run full suite of tests for linux32 configuration.

So far only the examples have been regularly tested on linux32. Try running the
full suite to see what comes up.

If this goes well, we can consider running the full suite for no-local.linux32
too.
Document (briefly) our behavior when copying extern structs

Specifically those whose fields are not completely specified in Chapel code.
Merge pull request #803 from lydia-duncan/crazyRecordBaseline

Fix errors involving --no-remove-copy-calls and partially defined extern structs
[reviewed by hilde]

Previously, if an extern type was partially defined in Chapel code, the
remaining fields would lose their values in certain circumstances (namely when
an initCopy was used). The initCopy would take in an instance of that record,
copy the fields whose existence it understood, and then pass in an uninitialized
instance of the type to the constructor. To preserve the values Chapel did not
understand, the argument to initCopy must be passed along to the constructor.

On Tom's suggestion, I also added a note to the spec about this behavior.
Merge pull request #805 from thomasvandoren/linux32-full-suite

Run full suite of tests for linux32 configuration.

So far only the examples have been regularly tested on linux32. Try running the
full suite to see what comes up.

If this goes well, we can consider running the full suite for no-local.linux32
too.