Disable task table by default

This commit disables task tracking and the task table by default.
This cuts down on the size of the generated code and compile time
significantly.  The argument is that if your program fails
deterministically enough to be able to re-run with task tracking,
you can afford the time to recompile it.

We could make this default to on for CHPL_TASKS=fifo (the only place
it works currently anyway), but that suggests that once qthreads
supported it, we'd want it to default on there too, and I'm not sure
that's the case.  Or else we'd want to disable it in testing by
default.
Merge branch 'master' of https://github.com/chapel-lang/chapel into noTaskTable
Added a routine to warn if this flag is used when CHPL_TASKS != fifo

(since none of the tasking runtime layers call into this module
other than that one).
Merge branch 'master' of https://github.com/chapel-lang/chapel into noTaskTable
Add --task-tracking flag to tests that use it
Update to comments to reflect that these are stubs
Add new flag to expected help message
Merge branch 'master' of https://github.com/chapel-lang/chapel into noTaskTable
Fix for test/parallel/taskPar/sungeun/private.chpl

This test reasons about taskIDs directly (as do others, likely), so it
required functionality like the cast operation between taskIDs and
ints.  For that reason, and since these operations are cheaper than
the task table overall, I moved them into a new internal module called
ChapelTaskID that is used by ChapelStandard, making them available to
all programs, whether or not ChapelTaskTable is enabled via
--task-tracking.
Added a trailing linefeed
Merge branch 'noTaskTable' of https://github.com/bradcray/chapel into noTaskTable
Updating dead module count in Elliot's test.
Merge pull request #771 from bradcray/noTaskTable

Speed compilation by removing task table by default

[reviewed by @ronawho]

This commit kicks off a new category of "trademarked"
level-of-effort commits -- the "one-light-rail-ride-fix (TM)."

While looking through generated code for optimization
opportunities tonight and reflecting on a user's comment about
compilation speeds this week, I started to realize that we could
remove a lot of complexity from the generated code if we required
users to enable the task tracking table rather than always having
it on by default. This particularly makes sense in the
Qthreads-by-default world that we're in now, since the Qthreads
tasking layer doesn't even make callbacks into the TaskTable
module.

To that end, I added a new flag, --task-tracking, which enables
the task tracking support that we've always compiled in, while
--no-task-tracking (the default) disables it. To implement this,
I created a new modules/internal/tasktable/ directory with on/
and off/ subdirectories where the former contains the task
tracking code as always and the latter contains stubs for the
routines, the print routine of which contains a halt() telling you
to recompile with --task-tracking on if you want that feature.

Because only the fifo tasking layer uses the Chapel task tracking
table, the flag also generates a warning when it is thrown in
non-FIFO mode.

For a hello world program on my computer, this speeds compilation
from 6.79 seconds to 4.81 seconds. For a --no-local compilation,
it reduces it from 8.35 seconds to 5.58 seconds.

As part of this effort, I hoisted code related to taskIDs (which are
sometimes used independently of the task table by brave user code)
into its own internal module ChapelTaskID.chpl.

I updated tests that exercise the -b / -t flags to use the --task-tracking
flag.  These are skipif'd for everything other than fifo, not surprisingly.

Unrelated other than that I ran into it while debugging, I found that
we never print the internal module search paths, even when --devel
is set.  It seemed reasonable to print them in --devel mode (and was
helpful to my efforts) so I made this switch along the way.
Fix for last night's --baseline regressions

This commit fixes last night's glob baseline regressions.  The
cause of the problem is that, in --baseline mode, we introduce
variables of the fake glob_err_fn_t type that I declared in the
Chapel module; but since that type is never defined in C, we
get C runtime link errors.  This may be similar to the "extra
copies of extern types under baseline" issue that Lydia's been
running into.

I also found that I had to add wordexp and glob to the reserved
symbol names list even though I don't think we've had to do this
in the past (even though it makes sense that we would need to).
I wonder if this is somehow a darwin+baseline-specific thing?