Fix bug in cache
Stop adding duplicate fences in waitFor

Fences I added here are also added by the compiler
when --cache-remote is enabled, but they don't do
anything if --cache-remote is not enabled, so they
don't need to be explicitly included here.
Relax task counting fences, add barrier fence

The task counting atomics don't need to imply fences
as these are handled elsewhere and we're really just
updating a counter.

For the barrier here, it's waiting on (not atomic)
local memory to change from a remote locale's put - which
is not legit according to the memory model... add
a fence (but I'd like to see a better barrier).
A whitespace cleanup in preparation for fixing some issues with module use data in ModuleSymbol and BlockStmt
Moved tracking the current PID to the modules

The privatized object count was previously tracked via in the runtime.
Now, it is an atomic integer in the modules that is passed into the
runtime when creating new privatized classes.
Updated some .goods that changed after moving the pid into the modules
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.
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.)
Merge pull request #43 from noakesmichael/mod-use-2

Preliminary "whitespace" cleanup in preparation for tackling a few simple issues with Module uses

Module use information is logically located in 4 places; use-statements in the AST, the modUses property of BlockStmt, the modUseList/modUseSet on ModuleSymbol.  These are being managed at multiple points in the code and there are some consistency issues right now.  I am going to fix a few of these issues to advance the interpreter.  This is a "whitespace cleanup" so that the code reviews for the functional changes will be easier.

compiled: clang on STD, gnu on STD/LLVM
tested:     paratest without --verify
reviewed: Elliot
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 modUsesSet from ModuleSymbol and localize data management of module use information to ModuleSymbol
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.