Testing changes to prepare for --[no-]use-noinit flag

Updates the test on our -h flag to include the information about the new flag.
Adds a test directory devoted to use of the flag --no-use-noinit, and a case to
verify --use-noinit behaves the same as the default behavior.  Skips my noinit
test directory when --no-use-noinit is used, as the output will be different
(and the important cases are covered in the compflags directory).
Implementation of the --[no-]use-noinit flag

Adds the flag --[no-]use-noinit to the language, with a default of --use-noinit.
This allows the user to control whether the use of noinit within their code
(and module code) is honored at compile time, allowing them to easily determine
the impact noinit has on the performance of their program.

Implementation details:

--use-noinit controls the insertion of the primitive PRIM_NO_INIT in normalize
for user code.  I could have alterred the the functionResolution behavior in
response to noinit, but that was more complicated (and also would have resulted
in the unnecessary insertion and replacement of PRIM_NO_INIT wherever it was
otherwise needed).  Thus, I felt that making the switch during normalize was
the better course of action.

Noinit must still be used with return temps, because our default initialization
lives in the modules - default initializing the return temps in the default
initialization functions (soon to be methods) would cause infinite recursion to
occur.  Thus, --no-use-noinit does not affect return temps.  This should not be
a detail that is apparent to the user, as it is specific to our implementation.
If we do encounter an error related to this, then I will have a bug to fix.
Fix whitespace issues.
Fix the man page entry.
Merge branch 'master' into addIgnoreNoinitFlag
Fix errors with strings and complexes by always allowing noinit in module code

This is a bit of an artifact of how default values are implemented in the
modules.  There are some _defaultOf functions which must define an instance of
that type in order to initialize it.  Obviously these cases need to skip default
initialization for that instance or infinite recursion will occur.  Our
intention moving forward is that types will define their default through the use
of constructors, which would remove the need for noinit in these cases, but
since we are not there yet, it is necessary to ignore --no-use-noinit in the
provided module code.  While a bit heavy-handed, this is a reasonable approach
to take because the internal modules and standard modules should be considered
an implementation detail - steps taken to ensure their operability in all
circumstances should not be breakable by user code and compilation actions, or
our implementation would be incorrect.

At this time, there is no use of noinit in the module code solely for
performance (though as an implementation detail, it would not be unreasonable to
ensure noinit was always honored for that use).
One more test change

The test compflags/lydia/noUseNoinit/noinitSkippedCase.chpl specifically intends
to test the default and alterred behavior in regards to the --no-use-noinit
flag.  Throwing the flag with start_test alters the test's behavior and
circumvents its purpose, so skip the test when the flag is used.

I did not add a similar skipif to execflags/sungeun/about, because I don't think
we intend to run nightly --no-use-noinit testing (at least, not yet).  The
skipif file for that test seems to consist of flags we use for nightly testing.
If someone wishes to run this flag over the whole test suite, they should know
it might fail.

I also did not add a similar skipif for functions/hilde/defaultOf/precedence or
functions/lydia/userDefinedDefaultFunction/*, though these tests depend on
noinit to work.  My reasoning here is that their dependence on noinit is related
to their implementation, and since we intend to alter the implementation of
default determination to utilize constructors rather than the _defaultOf
function, it is important that these tests get noticed as still breaking with
--no-use-noinit when the implementation has changed.
Add some clarifying comments.
Merge pull request #1017 from lydia-duncan/addIgnoreNoinitFlag

Add flag to ignore/enable noinit [reviewed by hilde]

Adds the flag --[no-]use-noinit to the language, with a default of --use-noinit.
This allows the user to control whether the use of noinit within their code
(and module code) is honored at compile time, allowing them to easily determine
the impact noinit has on the performance of their program.

Implementation details:

--use-noinit controls the insertion of the primitive PRIM_NO_INIT in normalize
for user code. I could have altered the the functionResolution behavior in
response to noinit, but that was more complicated (and also would have resulted
in the unnecessary insertion and replacement of PRIM_NO_INIT wherever it was
otherwise needed). Thus, I felt that making the switch during normalize was
the better course of action.

There is some cruft in this change due to the current state of the language.
Most of the cruft is expected to disappear in the near future.  In particular:
noinit must still be used with return temps, because our default initialization
lives in the modules - default initializing the return temps in the default
initialization functions (soon to be methods) would cause infinite recursion to
occur. Thus, --no-use-noinit does not affect return temps. This should not be
a detail that is apparent to the user, as it is specific to our implementation.
If we do encounter an error related to this, then I will have a bug to fix.
Similarly, noinit must still be used within our internal and standard modules.
There are some _defaultOf functions which must define an instance of
that type in order to initialize it. Obviously these cases need to skip default
initialization for that instance or infinite recursion will occur. Our
intention moving forward is that types will define their default through the use
of constructors, which would remove the need for noinit in these cases, but
since we are not there yet, it is necessary to ignore --no-use-noinit in the
provided module code. While a bit heavy-handed, this is a reasonable approach
to take because the internal modules and standard modules should be considered
an implementation detail - steps taken to ensure their operability in all
circumstances should not be breakable by user code and compilation actions, or
our implementation would be incorrect.

At this time, there is no use of noinit in the module code solely for
performance (though as an implementation detail, it would not be unreasonable to
ensure noinit was always honored for that use).

Testing details:
Updates the test on our -h flag to include the information about the new flag.
Adds a test directory devoted to use of the flag --no-use-noinit, and a case to
verify --use-noinit behaves the same as the default behavior (which we skip when
the --no-use-noinit flag is thrown for obvious reasons)

I ran std/ and std + --no-use-noinit. The former case passed without a hitch. The
latter had some hiccups, which resulted in varying solutions. My noinit test
directory is skipped, as the output will be different. (and the important cases
are covered in the compflags directory). The only remaining failures are
execflags/sungeun/about (the test requires that no flags be passed to the
function, we should really make that skipif more general), whose skipif I did
not alter because it consisted on modes we run nightly; and some tests
related to the redefinition of _defaultOf by the user
(functions/hilde/defaultOf/precedence and
functions/lydia/userDefinedDefaultFunction/*) - the behavior these tests are
verifying will change when we fully implement our constructor story, and I
believe the final constructor story would allow them to use the flag
--no-use-noinit without error. If it does not, further investigation should still
be made, so skipping them would hide that necessity.
Add a future related to param functions and intents

When a function with an out intent is converted into a syntactically valid param
function, the value of the out argument that is visible after the function has
executed is changed to the default value for that type.  This seems surprising
to me: if we don't expect out, inout, and ref intents to work for param
functions, we should generate an error message, and if we do expect them to
work, this is still a bug.  This future documents that tension.
Respond to Vass's comments on the pull request.
Merge pull request #1019 from lydia-duncan/paramFnFuture

Add a future related to param functions and intents [reviewed by vass]

When a function with an out intent is converted into a syntactically valid param
function, the value of the out argument that is visible after the function has
executed is changed to the default value for that type. This seems surprising
to me: if we don't expect out, inout, and ref intents to work for param
functions, we should generate an error message, and if we do expect them to
work, this is still a bug. This future documents that tension.
Change printchplenv to show uname on --debug
Merge pull request #1022 from Kyle-B/kb-printchplenv-tweak

Change printchplenv to show uname on --debug
Adding one typeselect future and one test showing its pointless

twoTypeSelects.chpl shows that the current implementation of
type select does not support multiple type selects in a single
Chapel program.  D'oh!  It's probably a five-minute fix to get
this working if one cared to.  By the time I'd written up the
description in the .future, it seemed like I also had the
solution.  But...

deprecateTypeSlect.chpl shows the syntax I'd prefer to use for
"type select" statements and was intended as a feature request
future; but it turns out to work.  So it raises the question
"Do we even need a type select anymore?"  Until someone argues
convincingly otherwise, my answer is "no, it seems like we
don't."
Merge pull request #1026 from bradcray/typeselect-futures

Adding one typeselect future and one test showing it's pointless

twoTypeSelects.chpl shows that the current implementation of
type select does not support multiple type selects in a single
Chapel program.  D'oh!  It's probably a five-minute fix to get
this working if one cared to.  By the time I'd written up the
description in the .future, it seemed like I also had the
solution.  But...

deprecateTypeSlect.chpl shows the syntax I'd prefer to use for
"type select" statements and was intended as a feature request
future; but it turns out to work.  So it raises the question
"Do we even need a type select anymore?"  Until someone argues
convincingly otherwise, my answer is "no, it seems like we
don't."