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.
And here I was thinking I didn't need to supplement my comment in this file.  Will fix.