Do not default initialize return temporary variables, where able.

This commit causes return variables to use noinit instead of default
initialization.  The rationale is that these variables will be assigned to
before they are returned, so default initializing them is a waste of time.
It is hoped that more compiler temporary variables can use this in the
future, but there are still some kinks to work out in the meanwhile.

Details of changes:
checkResolved.cpp:  The check for if a return variable has been assigned in
  all spots had two cases - first, if no assignment occurred; second, if
  only default initialization had occurred but the function had specified its
  return type.  In a world where return temps do not default initialize
  themselves except in special cases (see the commit on "pragma ignore
  noinit" for specific cases that must still default initialize themselves at
  this point in time), we would expect one or more assignments to occur in the
  ordinary case instead of at least two.  Externs being no longer special in
  this regard, it made sense to specify that this second case should only be
  triggered if the return type was one of the specified types that cannot use
  noinit.

normalize.cpp:  For the return temporary variables added here, unless the
  function is a param or type function, specify that the variables should not be
  default initialized unless necessary.  In the case of param or type variables,
  using noinit had caused confusion about whether the value returned really was
  what the return tag claimed, so we must continue to default initialize them
  for now.

functionResolution.cpp:  With normalize using noinit for return variables willy-
  nilly (as we don't know their type when return temps are inserted), it will
  not necessarily be the user's fault when noinit is applied to a type that
  can't use it.  This squashes that warning ("type <type> does not currently
  support noinit") in the case where the variable is a return temp and thus not
  the user's fault.
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.)
Merge pull request #45 from ronawho/qthreads-testing

See what the implications are for turning off qthreads affinity
Fixed a comment as Tom suggested.
Remove nostdlib/*.  This directory was removed in
https://github.com/chapel-lang/chapel/pull/31.
Merge pull request #46 from gbtitus/update-fast.suppress

Remove mention of nostdlib/*, which is no longer present.
Merge pull request #44 from lydia-duncan/noinitReturnTempsClean

Do not default initialize return temporary variables, where able.
Merge remote-tracking branch 'chapel-lang/master' into mod-use-2