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.
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.