Add timing for each sub_test call.

Register exit handler for sub_test python script that prints the elapsed
seconds from start up to exit (successful exit only). If sub_test is called
without CHPL_ONETEST, e.g. it is called on a directory, it will print a line
like the following when it is complete:

```
[Finished subtest "release/examples" - 16.330 seconds]
```

If sub_test is called with CHPL_ONETEST set, e.g. it is called on a specific
.chpl file, it will print a line like the following when it is complete:

```
[Finished subtest "release/examples/hello" - 2.711 seconds]
```

This will help developers do ad-hoc comparisons of nightly runs as needed. For
example, if a developer things a single test or new suite of tests is adding
significant time to the overall test time, it will be easy to find this line
and compare between two builds.

This is not meant to replace, or even enhance, compiler or runtime performance
tracking that already exists.
Fixing quickstart shells w.r.t. quickstart on Crays problem TMac hit today

Today, TMac started up a Cray Chapel environment building from source
in which CHPL_COMM would default to gasnet/aries or gasnet/gemini due
to being on a Cray, but the CHPL_MEM layer would be set to cstdlib
because of a seemingly innocuous change made to
util/quickstart/setchplenv.* when we made tcmalloc the default.
Because these GASNet conduits require tcmalloc or dlmalloc or the like
to register memory, an (vague) error is generated.

Here I'm addressing this by:

(a) making the quickstart files set CHPL_COMM to 'none' which arguably
    is what we might want people to start with, even on a Cray if
    they're building from source (and is already the default
    everywhere else);

(b) making the quickstart files not set CHPL_MEM.  This is something
    we will probably want to undo if/when we make tcmalloc the default
    at some point in the future.

Either one of these changes should be sufficient by itself.  Both
seemed like a better reflection of what we would want the quickstart
to do when building from source today.

Note that these changes won't affect Cray module users because they
get a different README and tend not to use the setchplenv.* scripts.
Remove a couple of debug lines
Merge branch 'master' of https://github.com/chapel-lang/chapel into add-timing-for-sub-test
Merge pull request #627 from bradcray/fix-cray-comm-mem-confusion

Fixing quickstart shells w.r.t. quickstart on Crays problem

Today, TMac started up a Cray Chapel environment building from source
in which CHPL_COMM would default to gasnet/aries or gasnet/gemini due
to being on a Cray, but the CHPL_MEM layer would be set to cstdlib
because of a seemingly innocuous change made to
util/quickstart/setchplenv.* when we made tcmalloc the default.
Because these GASNet conduits require tcmalloc or dlmalloc or the like
to register memory, an (vague) error is generated.

Here I'm addressing this by:

(a) making the quickstart files set CHPL_COMM to 'none' which arguably
    is what we might want people to start with, even on a Cray if
    they're building from source (and is already the default
    everywhere else);

(b) making the quickstart files not set CHPL_MEM.  This is something
    we will probably want to undo if/when we make tcmalloc the default
    at some point in the future.

Either one of these changes should be sufficient by itself.  Both
seemed like a better reflection of what we would want the quickstart
to do when building from source today.

Note that these changes won't affect Cray module users because they
get a different README and tend not to use the setchplenv.* scripts.
Merge pull request #611 from thomasvandoren/zsh-setchplenv

Update README to mention zsh as a bash-compatible shell.
Merge pull request #594 from thomasvandoren/add-warnings-opt

Enable C compiler warnings without setting CHPL_DEVELOPER.

Add new WARNINGS var in Makefiles. Set to 1 when CHPL_DEVELOPER is
defined. Use WARNINGS to enable warning flags in compiler specific makefiles.

Previously whether or not CHPL_DEVELOPER was defined determined if the warning
flags were added for C compiler. Instead, use the WARNINGS variable. This
allows a developers to build with compiler warnings enabled (e.g. when building
the runtime/) without the rest of the CHPL_DEVELOPER settings. Conversely, if
CHPL_DEVELOPER is set, a developer can disable C compiler warning flags by
setting WARNINGS=0 when calling make. The latter is not especially useful (or
recommended).
Set WARNINGS=1 instead of CHPL_DEVELOPER in nightly.

CHPL_DEVELOPER was added to nightly in commit 06088fc9. Based on internal
notes, it appears CHPL_DEVELOPER was added to enable additional C compiler
warnings. With pull request #594 those warnings can now be enabled by setting
WARNINGS=1 when calling make.
Update CHPL_DEVELOPER.txt docs.
Merge branch 'master' of github.com:chapel-lang/chapel into use-warnings-var-in-nightly

Conflicts:
	doc/developer/bestPractices/CHPL_DEVELOPER.txt
Remove CHPL_DEVELOPER from common.bash.
Add WARNINGS=1 when calling make in smokeTest.
Merge pull request #624 from hildeth/fixCStringsTail

Fix c_string related build and test regressions.
Merge pull request #617 from lydia-duncan/stringShootoutMod

String Shootout Update [reviewed by benharsh]

Update the string shootouts so that they will recognize the unused input value
sent to them through the Computer Language Benchmarks Game test suite.
Updating REGRESSIONS based on yesterday's runs and those that are in today
Add future for octal, binary, and hexadecimal command line arguments.

I discovered that sending in numbers beginning with 0x, 0b, or 0o via the
command line will lead to an error while attempting to convert the string value
received to an int.  I hope to have time to resolve this (if it is quick).
Add support for detecting cray-xe and cray-xc platform.

Look for CLEinfo config file, read it, and inspect the NETWORK value. If it is
"gem", set platform to "cray-xe". If it is "ari", set platform to "cray-xc".

If the CLEinfo file does not exist, or if it does not contain a known NETWORK
value, default to the old platform logic.
fix typos in chpl_platform
Merge pull request #629 from lydia-duncan/intConfigFuture

Add future for octal, binary, and hexadecimal command line arguments. [reviewed by daviditen]

I discovered that sending in numbers beginning with 0x, 0b, or 0o via the
command line will lead to an error while attempting to convert the string value
received to an int.  This is due to a lack of support for bin/oct/hex string -> int
casts.  Add a future for this case so that we don't forget about it.
Add explicit code to clean up GMP structure when done.