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
Add tag generation for the module code

Adds ctag support for chapel via the --regex and --lang[def|map] options
and uses it to generate tag files for our module code. `ctags -e` is now
used to generate the emacs format for compatibility with these options.

Also consolidated a few rules in the .gitignore for tag files, we now
generally ignore any tags or TAGS file.
Remove type declarations from Chapel tags

While it might be nice to have type declarations in the tags, we tend
to use them as variables in quite a few places and this leads to many
duplicate tags.
Add a new chpltags utility

chpltags wraps both Exuberant Ctags and etags, allowing for the creation
of both emacs and vi compatible tag files for Chapel code. This new
script is now being used to create the tag file for the modules. The
ctags.chapel file that was being used previously has been removed
Merged chapel-lang/master into standaloneParallelIterators

There were a few conflicts that needed to be cleaned up in build.cpp.
Tested with comm-gasnet.
Improve the chpltags help message

Improved the chpltags help message based on feedback from
@thomasvandoren.

Added a check to ensure that a ctags executable can be found before
calling it.
Revert the removal of fragmentLocalBlocks.

I was a bit aggressive in the removal of this function. This code is
needed when doing gasnet runs.
Move chpltags into the util/ directory

chpltags is now in the root util/ directory and has been added to the
release.
Merge pull request #925 from Kyle-B/kb-add-chapel-ctags

Add tag generation for the module code

Adds ctags support for chapel via a new utility script, `chpltags`. `chpltags`
uses the regex options supplied by ctags and etags.

`ctags -e` is now used to generate the emacs format for compatibility
with these options if possible, otherwise etags is used.

Also consolidated a few rules in the .gitignore for tag files, we now
generally ignore any tags or TAGS file.
Merge pull request #1002 from Kyle-B/kb-revert-fragmentLocalBlocks-removal

Revert the removal of fragmentLocalBlocks.

I was a bit aggressive in the removal of this function. This code is
needed when doing gasnet runs.
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