Update how we detect using intrinsics or locks for chpl_atomics
Update how we detect using intrinsics or locks for chpl_atomics

This will fix a build issue on netbsd32 where we mistakenly tried to use
atomics.

It also cleans up the checks so that it should work out of the box for future
platforms more easily. Previously we tried to use intrinsics for certain
versions of compilers so long as we weren't on linux32. This was a fragile
check from before we tested on other 32 bit platforms such as cygwin32 or
netbsd32.

I was going to update this script to special case for netbsd32 when I noticed
that we somehow get away with using the intrinsic atomic implementation on
cygwin32. After a little digging it turns out that gcc added support for 64 bit
atomics on 32 bit platforms with gcc 4.8. clang has always done this, and intel
also appears to (tested by looking at assembly when compiled with -m32.) They
basically use pthread locks to do atomic operations on 64 bit variables when
the hardware support isn't available.

There used to be a note in this script that mentioned we could do something
similar ourselves and use our intrinsics implement for 32 bit machines and
just use locks for 64 bit operations. gcc has done this for us, so we get it
for free if the backend compiler is new enough.

CoryMcCartan/chapel,CoryMcCartan/chapel,CoryMcCartan/chapel,hildeth/chapel,chizarlicious/chapel,hildeth/chapel,CoryMcCartan/chapel,chizarlicious/chapel,hildeth/chapel,hildeth/chapel,chizarlicious/chapel,hildeth/chapel,CoryMcCartan/chapel,hildeth/chapel,chizarlicious/chapel,chizarlicious/chapel,CoryMcCartan/chapel,hildeth/chapel,chizarlicious/chapel,chizarlicious/chapel,CoryMcCartan/chapel