Fix generic resolution of more complicated types with noinit
Not yet tested.
Merge branch 'master' into kill_test_module_sort_future
Change a warning to an error.  Previously, we had only warned if a function
specified its return type but did not return a value along one of its control
flow paths.  This will cause unpredictable behavior when return temps do not
initialize themselves by default (relying on other assignments to initialize).
Now, the behavior will be deterministic and will correctly not allow the
program to execute.
Update the previously known test case affected.

The test functions/hilde/retTypeNoRet.chpl displayed the warning behavior
described in the previous commit.  Since the test now fails to compile, I have
altered the .good file accordingly, and modified the test to only include the
minimum calls which will generate the error message.
This test previously generated a warning because the function did not return
a value when the return type was specified.  However, the point of the test was
a valgrind error that still exists when no return type is specified.  I decided
to remove the specified return type.  This program will now complete with only
the valgrind error remaining.
These five tests were properly checking that we detect when a function fails to
return a value, so it was appropriate to alter them for an error rather than a
warning with output.
Futurizing these tests.

As the functions in question currently stand, a value will always be returned,
but the compiler is under the impression this is not the case and so is
generating an error.  With proper analysis, these two cases should pass, so the
issue is now a future for both of them.
Merge pull request #39 from lydia-duncan/changeWarningToError

Change warning to error
A whitespace cleanup in preparation for fixing some issues with module use data in ModuleSymbol and BlockStmt
Merge pull request #37 from lydia-duncan/fixNoinitGenericResolutionPatch

Fix generic resolution of more complicated types with noinit
Using lowercase 'n' instead of 'N'
Merge pull request #41 from benharsh/fannk

Using lowercase 'n' instead of 'N'
Merge pull request #38 from hildeth/kill_test_module_sort_future

Remove .future from test_module_Sort-baseline in modules/hilde.
Remove some dead code
Fix an error for ordering #includes
Fix minor alignment issue in ModuleSymbol
Switch pointer comparisons to use NULL rather than 0
Revert to class initializer-lists for ModuleSymbol and BlockStmt
See what the implications are for turning off qthreads affinity

[more qthreads testing stuff, discussed with sung]

There are some for-loop and while-loop tests that are worse on chap04 (multi
socket) but not on chap03 (single socket.) The current guess is that because
qthreads pins shepherds to cores, if a core switches to another pthread, the
shepherd (and it's workers) can't make progress, meaning that qthreads could
perform worse in single threaded cases because. If shepherds are not pinned to
cores, that should mean that if the OS swaps the shepherds thread, that
shepherd should be able to move to a different core and continue making
progress but on a different core.

However, in cases where qthreads is using all systems resources, it seems
likely that we would want affinity (shepherds pinned to cores) but we're not
really sure of the implications yet, hence trying this.

Also it's possible that since we switched to using the nemesis scheduler, we
want affinity off for that, and only leave it on for configurations not using
nemesis (numa, using sherwood.)