Fix gmp build for 32bit ubuntu.

Need to set ABI=32 when calling ./configure.
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."
Add additional BigInt constructors for [u]int(64) args (where c_[u]long is expected).

A few tests in modules/standard/gmp were failing on linux32 to resolve calls
like "BigInt(bool, uint(64)" or "BigInt(int(64))". The intended constructors
were "BigInt(init2:bool, nbits:c_ulong)" and "BigInt(num:c_long)" respectively.

Create the [u]int(64) versions and cast from [u]int(64) to c_[u]long.
Get rid of c_[u]long BigInt constructors.

On 64bit platforms, they confuse function resolution as [u]int(64) and c_[u]long literals are the same.
Revert "Get rid of c_[u]long BigInt constructors."

This reverts commit d2883092b4be1fa14e21ee17461801d6b79c535a.
Revert "Add additional BigInt constructors for [u]int(64) args (where c_[u]long is expected)."

This reverts commit a87aca1209179319c83990de9654b2c73141548b.
Merge pull request #800 from thomasvandoren/fix-gmp-for-32bit-ubuntu

Fix gmp build for 32bit ubuntu.

Need to set ABI=32 when calling ./configure, at least for 32bit Ubuntu 14.04 desktop.

Without this setting, the configure step reports this error:

```
checking size of mp_limb_t... 4
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.
make: *** [gmp-config] Error 1
```
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.
Lower stack size for callStackSize test

This test is intended to show that the runtime changes stack size based off of
CHPL_RT_CALL_STACK_SIZE. It used to set the value to a little over 12MB.
However on cygwin our default and max stack size are 2MB so this just lowers
the value set to a little under 1MB. It doesn't really matter what the value is
so long as it's different than the default, and it's lower than the max across
different configurations.
Use uint(64) instead of c_ulong in BigInt pidigits versions.
Merge pull request #812 from thomasvandoren/update-pidigits-types

Use uint(64) instead of c_ulong in BigInt pidigits versions.
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 #811 from ronawho/update-callStackSize-for-cygwin

Lower stack size for callStackSize test

[ok'd by @bradcray]

This test is intended to show that the runtime changes stack size based off of
CHPL_RT_CALL_STACK_SIZE. It used to set the value to a little over 12MB.
However on cygwin our default and max stack size are 2MB so this just lowers
the value set to a little under 1MB. It doesn't really matter what the value is
so long as it's different than the default, and it's lower than the max across
different configurations.
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.