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.
Minor cleanup of README.curl

Make the lines 80 characters long.  Add an apostrophe to
(2) Bindings to libcurl's curl_easy_setopt and curl_easy_perform
First draft of CONTRIBUTORS file

This is based primarily on memory -- I may find additional changes
while completing the CHANGES file.
Minor edits to README.auxIO

Makes sure the lines are at most 80 columns long, removes a reference to the
non-existent README.lustre, and switches "no one" to "no individual" in the last
entry, as I believe it is clearer this way.  Everything else looks fine.
Revert "Disable pidigits for llvm"
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).
Merge pull request #490 from chapel-lang/revert-487-disable-pidigits-for-llvm

Revert "Disable pidigits for llvm"
Snapshot of REGRESSIONS updates since last night
Add '-N 1' to the aprun command for KNC as we do for other node types.
Merge pull request #491 from bradcray/triage-sep-blc

Snapshot of REGRESSIONS updates since last night

Failures:
* new compilation issue for Sung's memLeaks/promotion (should now be fixed)
* lingering regression for memLeaks/coforall for GASNet only (sungeun)
* pidigits failing on llvm due to enabling that combination for the first time (expected)
* filerator/walk failing on cygwin due to missing /bin/sh (can't reproduce)

Improvements:
* Vass's sync/single by generic regressions fixed (but still lingering on a few platforms due to lag in testing -- moved them down to the appropriate categories for tracking)
* Lydia's case-sensitivity darwin regressions fixed (but still listed on cygwin due to testing lag)
* miniMD fixed on darwin for reasons I don't understand (maybe I misdiagnosed?)
* regexp_channel_test working on cygwin for reasons I don't understand
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.
Add a README for the new file functions.
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.