Like other third-party packages, build the static, but not dynamic gmp libs

GMP seems to be breaking on the cray-prgenv-* builds, and I think that
the attempt to build .so's is the reason.  We could selectively disable
.so's on Crays, but since we disable the .so's in every other third-party
package, why not here as well?

Thomas is going to test this branch to see whether it fixes the GMP
builds on cray-prgenv-*.
Filter the --enable-static/--disable-shared flags only for Cray platforms

This should make the C compile-time warning go away for Mac while
avoding building the .so's on Crays.  It's also most similar to what
we've been testing by default for the past several months.
First draft of CONTRIBUTORS file

This is based primarily on memory -- I may find additional changes
while completing the CHANGES file.
At Thomas's suggestion, extending the filter to include cray-x*

(in order to avoid disabling for cray-cs, which can probably
better handle the .so's).
Add '-N 1' to the aprun command for KNC as we do for other node types.
Remove --no-bounds-checks compopts from "maximal" range tests

This removes the --no-bounds-checks compopts from
  test/trivial/deitz/test_max_range_iteration
  test/types/range/elliot/test_min_and_max_range_iteration

The original intent of having the explicit --bounds-checks and
--no-bounds-checks was to not have to worry about what the test would do
normally vs for --fast testing. The no-bounds-checks versions were expected to
overflow and cause an infinite loop that the test program would detect.
However, since these two tests would result in signed overflow and signed
overflow is undefined in c anything can happen. For most compilers this did
result in infinite loops, but for the cray compiler the tests stopped like you
would expect a regular loop to, which was a little surprising at first but is
fine since the behavior is undefined.

types/range/hilde/maximalRange did not need to change since unsigned
integer overflow is well defined.
Minor edits to README.hdfs

Added a comma, changed the tense of one verb to match the tense of those listed
in the previous steps, and changed some demonstrative pronouns to more specific
descriptions for greater clarity.
Merge pull request #492 from sungeunchoi/knc-test

Add '-N 1' to the aprun command for KNC as we do for other node types.
Merge pull request #494 from lydia-duncan/docFreezeHDFS

Minor edits to README.hdfs [reviewed by Ben]

Added a comma, changed the tense of one verb to match the tense of those listed
in the previous steps, and changed some demonstrative pronouns to more specific
descriptions for greater clarity.
Add chpl_task_yield() to assoc stress tests to quiet testing.

These tests have been timing out intermittently in nightly testing. They usually
finish fairly quickly, but every now and again they run absurdly slow (though
I'm pretty sure they're still making progress)

This just adds chpl_task_yield()'s to quiet testing. This is NOT a fix for the
core problem.

This is one of the tests that deadlocked with the switch from sherwood to
nemesis for qthreads scheduler. The core issue was that tasks get assigned to
workers round robin and the tasks that are incrementing a sync variable were
being assigned to a worker that was waiting for the sync variable to have a
certain value, and that task was never yielding. There were several commits to
address that and this test always passes given enough time, but for some reason
it finishes slowly sometimes.

There is a pivotal item to make sure we don't forget about this:
https://www.pivotaltracker.com/n/projects/1028642/stories/79146968

We don't believe this is a big issue, or one that has performance/correctness
implications for "real" tests.
Set processing elems per node when using PBSPro launcher.

This is how we feel about it: http://goo.gl/B6gcYe
Merge pull request #495 from ronawho/qthreads-testing

Add chpl_task_yield() to assoc stress tests to quiet testing.

[discussed with @gbtitus]

These tests have been timing out intermittently in nightly testing. They usually
finish fairly quickly, but every now and again they run absurdly slow (though
I'm pretty sure they're still making progress)

This just adds chpl_task_yield()'s to quiet testing. This is NOT a fix for the
core problem.

This is one of the tests that deadlocked with the switch from sherwood to
nemesis for qthreads scheduler. The core issue was that tasks get assigned to
workers round robin and the tasks that are incrementing a sync variable were
being assigned to a worker that was waiting for the sync variable to have a
certain value, and that task was never yielding. There were several commits to
address that and this test always passes given enough time, but for some reason
it finishes slowly sometimes.

There is a pivotal item to make sure we don't forget about this:
https://www.pivotaltracker.com/n/projects/1028642/stories/79146968

We don't believe this is a big issue, or one that has performance/correctness
implications for "real" tests.
Update the man page and README.chplenv for release.

In README.chplenv, CHPL_MODULE_PATH was not mentioned, so I added an "Optionally ..."
section to cover it.  I also mention that "curl" is now a valid setting for
CHPL_AUX_FILESYS, and direct readers to technotes/README.curl for details.

Entries in the ENVIRONMENT section were alphabetized.  The descriptions were not altered
and none added nor deleted.
Merge pull request #496 from ronawho/CForLoops-cleanup

Remove --no-bounds-checks compopts from "maximal" range tests

This removes the --no-bounds-checks compopts from
test/trivial/deitz/test_max_range_iteration
test/types/range/elliot/test_min_and_max_range_iteration

The original intent of having the explicit --bounds-checks and
--no-bounds-checks was to not have to worry about what the test would do
normally vs for --fast testing. The no-bounds-checks versions were expected to
overflow and cause an infinite loop that the test program would detect.
However, since these two tests would result in signed overflow and signed
overflow is undefined in c anything can happen. For most compilers this did
result in infinite loops, but for the cray compiler the tests stopped like you
would expect a regular loop to, which was a little surprising at first but is
fine since the behavior is undefined.

types/range/hilde/maximalRange did not need to change since unsigned
integer overflow is well defined.
Merge pull request #486 from bradcray/build-git-static-only

Build gmp static only on Crays

[co-developed with Thomas]

It turns out that when speculatively building GMP using Cray PrgEnv's
using our existing Makefile logic, we get build errors due to its attempt
to build/test .so files.  Note that for most other third-party packages,
we don't build .so files and that GMP is somewhat of an outlier in this
regard.

For those who track these things, the original proposal was going to be to
disable-shared for all builds, similar to what we do for most other
third-party packages.  The reason we backed away from this and only did it
for Crays was (a) disabling shared resulted in warnings when compiling GMP
programs on Macs and (b) it minimizes the delta for other platforms
relative to what we've been testing for the past several months.
Merge pull request #497 from thomasvandoren/fix-launchcmd-for-pbsproc

Set processing elems per node when using PBSPro launcher.

This is how we feel about it: http://goo.gl/B6gcYe
Back out reordering of ENVIRONMENT entries.
Snapshot of CHANGES so far (not far yet)
Adding a test that calls functions from different modules without using the module directly.
Merge pull request #501 from sungeunchoi/test

Add test for calling functions from a module with out using the module.

This test calls X.f() and Z.f() without using X (in same file) or Z (in different file).