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
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.
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)
Add function ParamForLoop* toParamForLoop(BaseAST* a)
Implement ParamForLoop::copy()
Implement a function that produces a copy of the body, a BlockStmt, of a ParamForLoop
Simplify BlockStmt::isLoopStmt()
Add a short-circuit for ParamForLoop to isDefinedAllPaths()
Clarify use of blockInfoGet() in is_param_resolved()
In fold_param_for 1) Clarify that block is in fact a ParamForLoop 2) Copy the body of the ParamForLoop as a BlockStmt
Merge pull request #992 from bradcray/globUseLydiasIsLink

Change Filerator to use isLink(), isDir(), isFile()

Previously, I had been using my own home-cooked runtime query to
determine whether something was a directory and/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.

The only thing that's slightly ugly about my approach is how I
'use'd the FileSystem module.  I wanted to use it at the
procedure scope, but doing so seemed to shadow my 'path'
variable with a (compiler-introduced?) method of the same name.
So instead, I inserted an artificial innermost scope to contain
the 'use'.  This may be a short-term workaround because I think
that ultimately (once the names are finalized), these iterators
should be incorporated into the FileSystem module anyway
(at which point the 'use' will no longer be necessary).

I added a future demonstrating this surprise shadowing behavior.
I think it's similar to one that Kyle has submitted previously (noted
in the future itself).

Most of the diff here is (happily) dead code elimination.
Merge pull request #993 from noakesmichael/param-for-loop-3

Improve touch points between ParamForLoop and function resolution

1) There were places in resolve where a ParamForLoop was being "quietly" converted in to a BlockStmt;
some good, some bad.  Add copy() and copyBody() to do this in a more controlled manner

2) Fix up a couple f call sites that were calling blockInfoGet() on the propagated ParamForLoop


Compiled: STD clang/darwin, STD gcc/linux64, LLVM gcc/linux64
Tested: paratest --verify
Review: none
Whitespace cleanup 1
Convert fold_param_for/param_for_index_type to take ParamForLoop* rather than the CallExpr* from the blockInfo