Update cobegin-stacksize.

This test was originally added with the following message:

"Add a test that fails (on linux systems, anyway) unless the new callStackSize
config const is set at execution time, as it is in the .execopts file here."

However the failure mode really depends on the configuration (--baseline,
default, --fast) and exactly what code we're generating. Currently this tests
pases with default without setting CHPL_RT_CALL_STACK_SIZE so it's not really
testing what it intended to anymore (which I think is just that
CHPL_RT_CALL_STACK_SIZE actually changes the call stack size beyond just what
the tasking layer reports to us.)

To make it more portable to different configurations this updates so the test
runs in two modes. One with 32KB which will always fail, and one with 32MB
which should always pass.
Update cobegin-stacksize execopts based on Greg's feedback

Don't need the B in MB/KB.

"The 'B' won't hurt anything (it'll be ignored), but having it there might
confuse people into thinking it was necessary/meaningful."
Update the problem size and stack limits so this test works on cygwin

default and max stack size on cygwin is 2MB because setrlimit doesn't work.
Update callStackSize

The minimum call stack size for fifo is 16K, so I updated the min call stack
size tried. However, 16K is too small to get a failure with --fast so I added a
skipif for --fast.

The failure mode is different on various platforms/configurations (linux vs mac
vs cygwin and valgrind vs no valgrind.) I added a prediff to deal with these
variations
Update callStackSize

Added comments to the compopts.

Also added skipif for cygwin. I thought we could at least lower stacksize on
cygwin but that doesn't appear to be true. I know setrlimit doesn't work, but
I thought we could at least limit the pthreads stack size with
pthread_attr_setstacksize
Merge pull request #810 from ronawho/update-cobegin-stacksize

Update cobegin stacksize

[reviewed by @gbtitus]

This test was originally added with the following message:

"Add a test that fails (on linux systems, anyway) unless the new callStackSize
config const is set at execution time, as it is in the .execopts file here."

However the failure mode really depends on the configuration (--baseline,
default, --fast) and exactly what code we're generating. Currently this tests
passes with default without setting CHPL_RT_CALL_STACK_SIZE so it's not really
testing what it intended to anymore (which I think is just that
CHPL_RT_CALL_STACK_SIZE actually changes the call stack size beyond just what
the tasking layer reports to us.)

To make it more portable to different configurations this updates so the test
runs in two modes. One with 16K which will always fail, and one with 2MB
which should always pass.

The problem size was updated to use these stack sizes, and the stack sizes were 
chosen so the test works on most of our platforms. 16K is the smallest stack size
allowed for fifo, and 2MB was chosen with the hope it would work with cygwin. 

With --fast the stack frames are so small that it can recurse a lot with 16K stack 
frames so it we just skip that configuration. Cygwin apparently doesn't respect 
pthread_attr_setstacksize so it always uses 2MB stack regardless as to what
we set so we also skip it there.
Strip new lines from proc count in nightly (et al).

Before this change, the make calls, `make -j$num_procs ... compiler`, were
putting the target on a separate line. This caused everything that uses these
scripts to fail last night.
Merge pull request #813 from thomasvandoren/fix-nightly-num-procs

Strip new lines from proc count in nightly (et al).

Before this change, the make calls, `make -j$num_procs ... compiler`, were
putting the target on a separate line. This caused everything that uses these
scripts to fail last night.