With GASNet amudprun+ssh launch, forward environment to user process.

GASNet's amudprun launcher does not forward the environment from the
launcher to the the user processes.  Do it ourselves in this case, using
the new -E option to the user program.

runtime/src/launch/amudprun/launch-amudprun.c
  If we using the ssh spawner, add the environment to the user program
  command line via the new -E option.
  While here, I also did a little cleaning up: moved _nlbuf (renamed to
  nlbuf, what's with the leading '_' on a file-static var?) into the
  only function that uses it, and changed sprintf(3) to snprintf(3) in
  the two places where we print into limited-size buffers.  The buffers
  should always be long enough, but it's still good style.  I also got
  rid of a pair of comments that didn't seem to be adding anything.

test/execflags/gbt/getenv.chpl
test/execflags/gbt/getenv.execenv
test/execflags/gbt/getenv.good
test/execflags/gbt/getenv.numlocales
test/execflags/gbt/getenv.skipif
  Add a test that runs only for comm=gasnet, and checks that a user
  environment variable is available.
For GASNet udp conduit + ssh spawner, send env to user prog via -E options.

This modifies our amudprun launcher to send all of the environment
variables to the user program instances via -E options.  Unfortunately,
doing so requires an update to GASNet, because the udp conduit's ssh
spawner can only handle 1024-byte command lines and the ones this mod
causes us to create are quite a lot larger than that.

The file-specific changes are as follows.

runtime/src/arg.c
Send a -E option to the user (*_real) program for every environment
setting.

third-party/gasnet/GASNet-1.22.0/other/amudp/amudp_spawn.cpp
Modify the udp conduit's ssh spawner to handl;e command lines of
arbitrary length.

third-party/gasnet/GASNet-1.22.0/gasnet_trace.c
Allow for much longer command lines in the tracing code.  I didn't do a
full solution for arbitrary-length command lines here, because command
line buffers with statrically determined lengths are everywhere in
GASNet and where would it all end?

test/execflags/gbt/getenv.good
test/execflags/gbt/getenv.prediff
Update the test that checks for correct functioning of this feature.
Put the GASNet source files back how they were. I'm going to apply the
official GASNet version of the changes to those files instead.
Remove arbitrary limit on command line length

This commit is a minor variation on one contributed by Greg Titus
of Cray.  The purpose is to remove the arbitrary 1024-character
limit on the length of the ssh command line run via system() when
AMUDP is using SPAWNFN=S.  This allows for a much longer command
line, as required by the Chapel runtime when using this spawner.
Always tell qthreads how many threads we want to use

Previously we only told qthreads how many threads to use if a user set
CHPL_RT_NUM_THREADS_PER_LOCALE or if they set the qthreads variables
themselves.

However this became a problem (led to performance regressions) when switching
to the nemesis scheduler. The affinity layer seems to assume a multi-threaded
shepherd is being used.  Previously we patched qthreads to correct the number
of workers and workers per shepherd after the affinity layer setup, but the
problem was that the affinity layer was still using the bad information to pin
threads to cores.

With this we now always specify the number of threads to use. We default to num
cores on a node (which is what we used to try and get qthreads to do
automatically.)

Previously we always set worker_unit=core (unless the user set it explicitly.)
Now we only set that if num threads <= num cores, otherwise we set pu. Note
that pu is the qthreads default, but we explicitly set it, since that default
is documented, but might change in the future.

The only policy this changes for us is that we no longer always set
worker_unit=core, other than that this is just cleanup/fixing things so we get
our previous policy correct again.

Some more details:
 - Added an include for qt_shepherd_innards.h to get the threadqueue policy (so
   we either set num_shepherds/num_wps, or set hwpar an let qthreads figure it
   out.)

 - Added macro for the size we use for looking at qthread environment
   variables. We were pretty good at using 100, but this seems easier. 100
   matches the size that qthreads uses, although they just use the literal
   everywhere rather than having a marco.

 - Adds a function to check if the user set the qthreads level variables for
   the number of threads.

 - Clean up some comments.

 - Always unset qthread variables for controlling number of threads. We either
   override them in the case that CHPL_RT_NUM_THREADS_PER_LOCALE was set, reset
   them (and maybe limit to commMax) if the user set them themselves, or for
   the default they were never set, so it doesn't hurt to unset them.
Whoops, put the macro for env var size in an ifdef for profiling
readd comment that we limit CHPL_RT_NUM_THREADS_PER_LOCALE to numPUsPerNode
Merge pull request #194 from gbtitus/amudprun-forward-env

with GASNet udp conduit and ssh spawning, forward the environment

[Reviewed by Sung.]

GASNet's udp conduit and ssh spawner do not forward the environment from
the launching process to the user processes. We therefore need to do it
ourselves. To achieve this, in our amudprun launcher add a -E option
for each environment variable to the command line for the user program.

runtime/src/launch/amudprun/launch-amudprun.c
If we are using the ssh spawner, add the environment to the user
program command line via the new -E option.

While here, I also did a little cleaning up. I moved nlbuf into the
only function that uses it. While doing so I renamed _nlbuf to nlbuf;
the leading '' seemed extraneous. I also changed sprintf(3) to
snprintf(3) in the two places where we print into limited-size
buffers. The buffers should always be long enough, but it's still
good style. And, I got rid of a pair of comments that didn't seem to
be adding anything.

runtime/src/arg.c
Don't print a warning when we see a -E option for an env var that is
already set. It turns out there are lots of these, set by various
things that run before the user executable in the remote ssh session.
The warnings are therefore unavoidable and just add noise.

third-party/gasnet/GASNet-1.22.0/other/amudp/amudp_spawn.cpp
Allow command lines of arbitrary length in the udp conduit's ssh
spawner. The old code only allowed 1024 characters, used a fixed
size buffer, and didn't check for overflow. Adding the entire
environment to the command line typically requires way more than 1024
characters. The change here duplicates this GASNet commit:
https://bitbucket.org/berkeleylab/gasnet/commits/1abde2638f58790b6e649ad23d\
42a19a6b3166d3

This is a minor modification of some code I sent Paul Hargrove. To
ease future merges, I'm committing his version instead of my original.
(I committed and then backed out mine in my branch, so anyone curious
can dig it up.)

test/execflags/gbt/getenv.chpl
test/execflags/gbt/getenv.execenv
test/execflags/gbt/getenv.good
test/execflags/gbt/getenv.numlocales
test/execflags/gbt/getenv.prediff
test/execflags/gbt/getenv.skipif
Add a test that runs only for comm=gasnet, and checks that a user
environment variable is available.
Remove hwloc 1.7.2, no longer needed.

hwloc 1.9 has been the default since June 28, so 1.7.2 can be deleted
now.
Merge pull request #197 from gbtitus/rm-hwloc-1.7

Remove hwloc 1.7.2, no longer needed

[Not reviewed.]

hwloc 1.9 has been the default since June 28, so 1.7.2 can be deleted
now.
Some updates

Move setting up the available parallelism and call stacks into their own
functions

Replace some uses of QT_ENV_S with sizeof(actual_var)

Remove the comments on the include files. Some of them aren't accurate and we

change verbosity == 2 to verbosity >= 2

No longer set number of threads, or WORKER_UNIT if the user set QT_NUM_WORKERS
or QT_NUM_WORKERS_PER_SHEPHERD (assume "expert" user.)
Clean up comments
Fix spelling error
Merge pull request #195 from ronawho/qthreads-set-hwpar-hints

Ensure qthreads is always told how many threads to use

[reviewed by @gbtitus]

Previously we only told qthreads how many threads to use if a user set
CHPL_RT_NUM_THREADS_PER_LOCALE or if they set the qthreads variables
themselves. Otherwise we just let qthreads figure it out on it's own.

However this became a problem (led to performance regressions) when switching
to the nemesis scheduler. The affinity layer seems to assume a multi-threaded
shepherd is being used. Previously we patched qthreads to correct the number
of workers and workers per shepherd after the affinity layer setup, but the
problem was that the affinity layer was still using the bad information to pin
threads to cores.

With this we now always specify the number of threads to use. We default to num
cores on a node (which is what we used to try and get qthreads to do
automatically.) If a user specified CHPL_RT_NUM_THREADS_PER_LOCALE we limit
this to numPUs and commMax, and then set the appropriate qthreads variables
(which ones depends on the scheduler type.) If a user sets hwpar we do
something similar to what we do for CHPL_RT_NUM_THREADS_PER_LOCALE, we just
don't limit to numPU (this is how a user can oversubscribe the hardware if they
really want to.) And lastly if the user set QT_NUM_SHEPHERDS or
QT_NUM_WORKERS_PER_SHEPHERD we assume they are an expert user and so we don't
do anything else to setup the number of threads or the worker unit.

Previously we always set worker_unit=core (unless the user set it explicitly.)
Now we only set that if the user didn't set QT_NUM_SHEP and/or QT_WPS and num
threads <= num cores, otherwise we set pu. Note that pu is the qthreads
default, but we explicitly set it since it might change in the future.

The only policy this changes for us is that we don't always set
worker_unit=core, other than that this is just cleanup/fixing things so we get
our previous policy correct again.

Some more details:

 - Added an include for qt_shepherd_innards.h to get the threadqueue policy (so
   we either set num_shepherds/num_wps, or set hwpar to let qthreads figure it
   out.)

 - Added macro for the size we use for looking at qthread environment
   variables. We were pretty good at using 100, but this seems easier. 100
   matches the size that qthreads uses, although they just use the literal
   everywhere rather than having a marco.

 - Adds a function to check if the user set the qthreads level variables for
   the number of threads.

 - Clean up some comments.

 - Split parallelism and call stack setup into two separate functions.
Revert "Change qthreads topology/affinity setup to work with nemesis"

This reverts commit 27d267d7e6167b11a11a66a5d07a9335f841a2e8.

This commit was intended to fix the number of shepherds and workers per
shepherd that qthreads used for single threaded schedulers like nemesis.
While it corrected the number, it did it after the affinity layer was setup
which meant that we had threads being poorly pinned to cores.

Now the chpl_task_init (or an expert user) is responsible for setting the right
number of shepherds and workers per shepherd before qthreads init, so we no
longer need this.
Merge pull request #198 from ronawho/qthreads-set-hwpar-hints

Revert "Change qthreads topology/affinity setup to work with nemesis"

This reverts commit 27d267d.

The original commit was intended to fix the number of shepherds and workers per
shepherd that qthreads used for single threaded schedulers like nemesis.
While it corrected the number, it did it after the affinity layer was setup
which meant that we had threads being poorly pinned to cores.

Now the chpl_task_init (or an expert user) is responsible for setting the right
number of shepherds and workers per shepherd before qthreads init, so we no
longer need this.