Remove modUsesSet from ModuleSymbol and localize data management of module use information to ModuleSymbol
Merge remote-tracking branch 'chapel-lang/master' into mod-use-2
Make some initial pbspro portability changes to launchcmd script.

Removes -d arg from qsub and instead calls `cd $PBS_O_WORKDIR` before calling
test command.
1) Insert a use-statement for ChapelStandard during parse 2) remove modUses after resolve
Factor much of the logic in pbs launchmd to class.

This will eventually be the basis for supporting both moab and pbspro flavors...
Fix ensure_sub instance method.
Fix reference to test_command.

The launchcmd script now works for moab/torque, as it did before...
Shuffle class method order.
Add a comment and some code to clarify that newAst could be NULL
Factor more things into AbstractJob and start separate impls of PbsProJob and MoabJob.
Fully realize MoabJob class with methods and attribute that will be different than PbsProJob.
Shuffle some comments.
Adopt names moduleUseAdd, moduleUseRemove, and moduleUseClear consistently for ModuleSymbol and BlockStmt
Implement PbsProJob class. This launchcmd now works with PBSPro!
Merge pull request #49 from noakesmichael/mod-use-2

Modify the way module uses are tracked and and managed.



(1) Update the parser so that ChapelStandard is included by inserting
a use-statement rather than sticking it directly in to the internal
data structures.  This makes thinking about the AST at the end of
parsing more consistent to the benefit of the compiler and interpreter.



(2) eliminate modUseSet from ModuleSymbol; the existing codebase spent
effort keeping modUseList and modUseSet in sync for negligible benefit



(3) centralize the management of ModuleSymbol::modUseList and
BlockStmt::modUses to those classes rather than being spread over the passes.

The new function ModuleSymbol::moduleUseAdd has a "temporary 
work-around" for an ordering issue in functionResolution that is
sensitive to the ordering of modules in this list for about 12 tests.
That issue needs more attention at some point.



(4) Clear BlockStmt::modUses after functionResolution.  This may also
prove to be a "temporary work-around" for issues in managing the
module use data-structures.  It is observably true that these lists
aren't used after functionResolution but they still change in
"unpredictable" ways.  This was causing problems in
deadCodeElimination.  Clearing these lists resolved the
issue for deadCodeElimination and was approved by Brad, but this
solution may ultimately prove to be short sighted.


Compiled: clang STD and gcc STD/LLVM
Tested:	  paratest --verify   woo hoo
Review:	  Elliot and Tom
Merge pull request #50 from thomasvandoren/pbs-pro

Update aprun launchcmd helper script to support both moab and PBSPro.
Enable "--enable-condwait-queue" for chap03/04 qthreads performance testing

[more chap03/04 qthreads performance tinkering, not reviewed]

Looking at some of the current performance regressions on chap04 for qthreads
it seemed that there was a pretty high performance penalty for purely serial
code. There doesn't seem to be a penalty on chap03 (or if there is, it's very
small.) However, I'm making the change there just to see what happens.

Using the "Loop Time Compare" graph as a case study:
 - This is a purely serial code, however with qthreads all 8 cores were getting
   pegged at 100%.
 - Manually setting QTHREAD_NUM_SHEPHERD=1 resolved the performance hit,
   indicating that there is interference from other shepherds.
 - enabling  qthreads over-subscription also resolved the performance hit. Then
   by going through each setting that over-subscription set, I saw the
   --enable-condwait-queue was responsible.

From qthreads:
  --enable-condwait-queue: force the use of a pthread condwait queue, instead
  of a spin-based queue for inter-thread communication (important if spinning
  shepherds interfere with each other). Default enabled on sparc/solaris, but
  default disabled elsewhere.

So it would seem that for serial code we "want" this set, but for highly
parallel code we wouldn't. I think the real solution should be that qthreads
should be able to see that it only has 1 task, and back the other workers off.

This is to see if the serial performance regressions are resolved, and to see
if and how much this hurts us for highly parallel cases.
Merge pull request #51 from ronawho/master

Enable "--enable-condwait-queue" for chap03/04 qthreads performance testing