Add flag to ignore/enable noinit

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.

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.
This is unfortunate.  If noinit is treated as an optimization, then the string implementation should also work when noinit --> default-init.  What is causing the string implementation to fail.  I would be much happier to see strings fixed so they did not depend on noinit-initialization and this section of code removed if at all possible.
"Push ugliness into the module code!"