Add -E support in executables, for use by launchers in forwarding the
environment to the user program processes when the underlying system
launcher can't do so.  The changes are:

runtime/src/arg.c
  Add -E option parsing and environment variable setting.

doc/release/README.executing
  Document the new option.

test/execflags/ferguson/help2.good
test/execflags/shannon/configs/help/basehelp.txt
test/execflags/shannon/help.good
  Update the expected "-h" output.

test/execflags/gbt/dash-E-1-opt.chpl
test/execflags/gbt/dash-E-1-opt.execopts
test/execflags/gbt/dash-E-1-opt.good
test/execflags/gbt/dash-E-1-opt.skipif
test/execflags/gbt/dash-E-2-opts.chpl
test/execflags/gbt/dash-E-2-opts.execopts
test/execflags/gbt/dash-E-2-opts.good
test/execflags/gbt/dash-E-2-opts.skipif
  New unit tests.
Merge branch 'master' of github.com:chapel-lang/chapel into dash-E
Ready for unit testing.
Merge branch 'master' of github.com:chapel-lang/chapel into dash-E
Snapshot:
- update parseArgs() to know whether it's the launcher or user
  executable and whether it's parsing -E options or others
- call parseArgs() early to do -E options in main, later for the rest
- call parseArgs() in the launcher
- Merge the two dash-E tests into one, with two .execopts entries.
Minor fixes to the -E test:
- Remove the second test (dash-E-2-opts).  There's only on dash-E test
  now, and it handles both the 1-arg and 2-args cases.
- Fix the skipif.  It was backwards.
Rework the -E support.

The significant change here is a complete rework of -E parsing.  In the
course of the review for the earlier version of this, we discovered a
major flaw: because regular command line processing runs after a certain
amount of runtime initialization has already happened, any -E options
that set environment variables needed during that initialization will
not have been seen yet.  In particular, comm layer initialization is
done before command line parsing, so for example GASNet environment
variables would not be available when the GASNet init function was
called.  Thus, -E environment variable setting cannot be done during
regular command line parsing -- that's too late.

To fix this problem, now -E parsing is done earlier, in a separate
command line parsing pass specifically for that purpose.  The major
changes (from the original code, not prior commits on this branch) are:
- The parseArgs() function now takes a mode to tell it whether to just
  parse for -E options or to do normal parsing.  It also takes a flag
  telling it whether it's being called in the launcher or not, since we
  have to skip -E options in normal parsing in the user executable
  (they've already been handled) but attend to them in the launcher
  (though, if they are present there, they have a different meaning).
- I didn't want to duplicate the case-by-case logic of normal parsing
  when doing the -E parsing, because it would create a maintenance
  burden when options changed.  However, during -E parsing we have to be
  able to skip the options that aren't -E ones, and this requires
  understanding which have a sub-argument and which do not.  So, I
  expanded the flagType type and flagList table so that each flag
  (option) has separate fields for its single-dash form, its
  sub-argument, and its double-dash form.  That allowed -E parsing to
  rely on the flagList table to decide when to take into account a
  sub-argument, without having to worry about exactly which flag was
  being dealing with.  As a result of this I also had to rewrite
  printHelpTable() completely, however.
- While in arg.c, I also removed some trailing white space on a few
  lines.

The secondary change here, to the .good files, was to make the help text
for -E show the sub-arg as "<envVar>=<val>" instead of "<name=value>",
as I had it in previous commits on this branch.  This makes it a lot
more like what we already show for "-s".
Update README.executing -E doc to match the help text.
Fix a couple of typos.
Merge pull request #27 from gbtitus/dash-E

add -E in user executables

Add -E support in executables, for use by launchers in forwarding the environment to the user program processes when the underlying system launcher can't do so. The changes are:

runtime/src/arg.c
The parseArgs() function now takes a mode to tell it whether to parse only the -E options or to do normal parsing. It also takes a flag telling it whether it's being called in the launcher or not, since we have to skip -E options in normal parsing in the user executable (they've already been handled) but attend to them in the launcher (although, if they are present there, they have a different meaning).

I didn't want -E parsing to duplicate the case-by-case logic of normal parsing, because that would create a maintenance burden when options changed. However, during -E parsing we have to be able to skip the options that aren't -E ones, and this requires understanding which have a sub-argument and which do not. So, I expanded the flagType type and flagList table so that each flag (option) has separate fields for its single-dash form, its sub-argument, and its double-dash form. That allowed -E parsing to rely on the flagList table to decide when to take into account a sub-argument, without having to worry about exactly which flag was being dealing with. As a result of this I also had to rewrite printHelpTable() completely, however.

While here, I also removed some trailing white space on a few lines.

doc/release/README.executing
Document the new option.

test/execflags/ferguson/help2.good
test/execflags/shannon/configs/help/basehelp.txt
test/execflags/shannon/help.good
Update the expected "-h" output.

test/execflags/gbt/dash-E.chpl
test/execflags/gbt/dash-E.execopts
test/execflags/gbt/dash-E.good
test/execflags/gbt/dash-E.skipif
New unit test.