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.
First cut at script that converts start_test log to jUnit xml report.
python 2.6 arg parser
Open logs with utf-8 encoding. Ignore invalid characters.
Fix bug when finding blocks.

If end was not found (-1) it was still added to the start value, which gave a bad end value.
Support jUnit xml style reports in start_test.

Add --junit-xml argument. When set, start_test calls new script to convert
logfile to junit xml style report. Also add --junit-xml-file argument, which
implies the --junit-xml argument. When --junit-xml-file is set, its value is
passed along to the conversion script as the junit xml output file.
Add jUnit XML report generation support to nightly.

Add -junit-xml flag to nightly that add --junit-xml flag when calling
start_test. The flag is thrown by default when JENKINS_URL is set in
environment (i.e. nightly is running inside jenkins job).
Filter invalid XML characters and wrap system-out in CDATA tag.
Add DEBUG setting.
Fix bug that showed up in linux32 logs.
Change Filerator to use isLink(), isDir(), isFile()

Previously, I had been using my own home-cooked runtime query to
determine whether something was a file, a directory, or a symbolic
link.  Now that Lydia (and Francisco?) have provided utility
functions for this, I can use theirs and get rid of some (now-dead)
code.
Updating comment to re-trigger Travis build.

The previous Travis build broke, but not for reasons due to my code
changes, it seemed, so kicking it back off again and making this
comment a bit more crisp while here.
Filing a "method shadows local" scoping bug

This bug is similar to the one that Kyle filed in
test/functions/kbrady/proc_scoping.chpl in which a
(compiler-generated?) method from a standard/internal module is
shadowing a local variable.  Intuitively, it seems to me that methods
should never do this, suggesting scoping is broken.  Somewhat
maddeningly, I've been unable to determine (in the time I've spent on
it so far) the root cause of the shadowing symbol.  See the .future
for further details.
Moved 'use' of FileSystem to a more logical, but artificially scoped place

On Lydia's request, moved 'use' of FileSystem into a closer scope and
removed the fully-qualified references to isDir(), isFile(), isLink().
Added a comment explaining the use of the scope and referring to the
future I just filed.
Revise signature of function resolveBlock(Expr* block) to be resolveBlockStmt(BlockStmt* blockStmt)