Add support for standalone parallel iterators

When a forall loop is parsed, it is translated into a call to the leader and
follower iterators, approximately:

for block in iter(leader) {
  for i in iter(follower, block) {
    body;
  }
}

For standalone iterators, we don't want this nested loop.  To accomplish this,i
I added a condition with a chpl__tryToken.  Now unzippered forall loops are
built as:

if chpl__tryToken {
  for i in iter(standalone) {
    body;
  }
} else {
  for block in iter(leader) {
    for i in iter(follower, block) {
      body;
    }
  }
}

This way, if a standalone parallel iterator exists and can be used, it will be
chosen and the leader-follower case will be folded out during resolution.  If
the standalone iterator does not exist, the standalone side will be removed and
the leader-follower branch will be used.  For the most part standalone
parallel iteration is treated the same as the leader case throughout the rest
of the compiler.  One main exception is that forall intents are not yet
implemented on the standalone side.

A simple standalone iterator is defined in the test
standaloneParallelIter.chpl.  It uses a coforall to generate parallelism
and define blocks and iterates over the blocks yielding individual elements.
It also defines a leader and follower iterator to verify the standalone
iterator is chosen over them and that zippered iteration still calls the
leader/followers.  Finally it uses a for loop that results in a serial
iterator getting called.

Tested on the full suite for standard linux64
Merged chapel-lang/master into standaloneParallelIterators

There were a few conflicts that needed to be cleaned up in build.cpp.
Tested with comm-gasnet.
Fix indentation on resolveExpr()
Introduce ParamForLoop::mResolveInfo to decouple ParamForLoop from BlockStmt
Introduce wrappers over the bundling for ResolveInfo
Migrate AstDumpToNode to the ParamForLoop field accessors
Replace trivial internal uses of paramInfoGet() with the accessors
Rename paramInfoGet() to resolveInfo() to emphasize the role of this information
Streamlined version of getFirstExpr/getNextExpr to clarify interaction with Resolve
Merge pull request #1004 from noakesmichael/param-for-loop-5

ParamForLoop: Continue to decouple from BlockStmt

The plan was to eliminate the use of a PRIM_BLOCK_PARAM_LOOP CallExpr to bundle up
the iterator state but I have been unable to do this; primarily due to subtle assumptions within
resolve/fold.

For the short term I've moved the CallExpr from BlockStmt to ParamForLoop and encapsulated most of
it behind wrappers. The challenging elements appear to be the delicate interaction between some AST
nodes and the macro for_exprs_postorder(), which relies on the ill-named getFirstExpr()/getNextExpr(),
as well as the function getStmtExpr().

I'll noodle on this some more but for now am moving on.

Compiled: STD clang/darwin, STD gcc/linux64, LLVM gcc/linux64
Tested: paratest --verify
Review: none
Add annotations for regressions from 12/05, 11/09

Simon's library mode commit seems to have impacted LULESH and binary-trees.
This doesn't quite make sense, but it's definitely the commit.  I will
investigate further into why this changed and if the impact can be reversed.

We also forgot to note when Brad turned off the task table, improving
compilation and the size of the generated code
Merge pull request #1005 from lydia-duncan/annotateDecPerfReg2

Add annotations for performance changes from 12/05, 11/09

Simon's library mode commit seems to have impacted LULESH and binary-trees.
This doesn't quite make sense, but it's definitely the commit. I will
investigate further into why this changed and if the impact can be reversed.

We also forgot to note when Brad turned off the task table, improving
compilation and the size of the generated code
Do a little cleanup and add some comments in standaloneParallelIterator code

Just a little cleaning up.
Undo uniquify dygraph csv names

This ended up causing way more issues than I expected, first with missing
graphs, and now it prevents annotations for single graphs from being applied.
Reverting the change altogether.
Remove extraneous add to inits in function resolution.

This line was the result of a bad "cut" command.  It was part of a previous if
clause that got removed, and somehow that left it in a different if clause than
where it started.  I reviewed the commit that allowed this, I should've caught
it.  The add was harmless, as it would be dead code the second time it was
reached and so skipped, but still.
Rename STREAM .graphs in studies directory

The csv files we generate for dygraphs get their name from the lowecase
basename of the .graph files. We had some duplicate basenames for some stream
tests. This renames the .graph files in the studies directory so we no longer
have a conflict. Previously we would override the .dat files, so the wrong data
was being loaded for some graphs.

An upcoming patch will add a check to make sure we don't run into this again.
Merge pull request #1008 from ronawho/uniquify-dygraph-csv-name

Undo code in gengraphs to make csv files unique

[reviewed by @lydia-duncan]

This was creating a lot more issues than I expected. I'm undoing the change, and changing the names of the .graph files that led to the non-unique csv files. 

The duplicate files were found with an upcoming patch that will make sure we don't run into this again: 323fb989b8ca2711fb15f1c5811d38a9eb8137f5
Respond to reviewer comment

Make buildStandaloneForallStmt static and remove the forward declaration
Merge pull request #1009 from lydia-duncan/removeExtraneousInsert

Remove extraneous add to inits in function resolution.

This line was the result of a bad "cut" command. It was part of a previous if
clause that got removed, and somehow that left it in a different if clause than
where it started. I reviewed the commit that allowed this, I should've caught
it. The add was harmless, as it would be dead code the second time it was
reached and so skipped, but still.
Merge pull request #1006 from daviditen/standaloneParallelIterator

Add support for standalone parallel iterators

When a forall loop is parsed, it is translated into a call to the leader and
follower iterators, approximately:

for block in iter(leader) {
  for i in iter(follower, block) {
    body;
  }
}
For standalone iterators, we don't want this nested loop. To accomplish
this, I added a condition with a chpl__tryToken. Now unzippered forall
loops are built as:

if chpl__tryToken {
  for i in iter(standalone) {
    body;
  }
} else {
  for block in iter(leader) {
    for i in iter(follower, block) {
      body;
    }
  }
}

This way, if a standalone parallel iterator exists and can be used, it will
be chosen and the leader-follower case will be folded out during resolution.
If the standalone iterator does not exist, the standalone side will be
removed and the leader-follower branch will be used. For the most part
standalone parallel iteration is treated the same as the leader case
throughout the rest of the compiler. One main exception is that forall
intents are not yet implemented on the standalone side.

A simple standalone iterator is defined in the test
standaloneParallelIter.chpl. It uses a coforall to generate parallelism
and define blocks and iterates over the blocks yielding individual elements.
It also defines a leader and follower iterator to verify the standalone
iterator is chosen over them and that zippered iteration still calls the
leader/followers. Finally it uses a for loop that results in a serial
iterator getting called.

Tested on the full suite for standard linux64 and linux64+gasnet
Reviewed by Vass