Allow the lcd architecture to be found for chapel modules

We add the architecture to the gen directory so that we can differentiate
between knc and non-knc builds. However, we build the module with the lowest
common denominator processor module loaded so that users can build with any
compatible processor module loaded and we don't have to build a binary for each
one. For instance, we build with sandybridge, but a user can have either
sandybridge or ivybridge loaded and the binaries will be compatible. However,
we would have sandybridge in the gen directory for the module, and the current
scripts would try to look for a gen directory with ivybridge in it. This adds a
routine in chpl_arch to get the lowest common denominator for the modules, and
gets it for the runtime in printchplenv iff a cray module is loaded, and it's
home location is the same as chapel home.

The reason for that is because a developer might have a module loaded, but also
have a working chapel repo that is their chapel home. Just because the module
is loaded, doesn't mean you need to get the lcd. You only want the lcd iff the
module is loaded, and the module binary is the one actually being used.
Style changes suggested by Kyle
Merge pull request #186 from ronawho/moduleLCD

Allow the lcd architecture to be found for chapel modules

[content reviewed by @gbtitus, python style by @Kyle-B]

We add the architecture to the gen directory so that we can differentiate
between knc and non-knc builds. However, we build the module with the lowest
common denominator processor module loaded so that users can build with any
compatible processor module loaded and we don't have to build a binary for each
one. For instance, we build with sandybridge, but a user can have either
sandybridge or ivybridge loaded and the binaries will be compatible. However,
we would have sandybridge in the gen directory for the module, and the current
scripts would try to look for a gen directory with ivybridge in it. This adds a
routine in chpl_arch to get the lowest common denominator for the modules, and
gets it for the runtime in printchplenv iff a cray module is loaded, and it's
home location is the same as chapel home.

The reason for that is because a developer might have a module loaded, but also
have a working chapel repo that is their chapel home. Just because the module
is loaded, doesn't mean you need to get the lcd. You only want the lcd iff the
module is loaded, and the module binary is the one actually being used.
First approach to a helper setenv function for qthreads

Want a helper function for qthreads to setenvs because qthreads has two
varations of each env var QT_VAR and QTHREAD_VAR and it's easy to forget to
check both. This also adds warnings if we don't set because the qthreads env
vars were already set by a user.
Update helper routine and actually use it

This updates the chpl_qt_setenv function with some more debug info and sets
the QTHREAD_ version of the env var too (just incase the precedence of QT_
every changes in the qthreads source.)

Also adds a TODO for the CALL_STACK env var and changes our uses of setenv to
chpl_qt_setenv
Didn't quote setting "core"
Fixes some bugs with print formatters that clang reports, but gcc doesn't

Just changes some print formatters.

Note that clang gives us a bunch of warnings about qthreads code that I shared
with the qthreads team. These were the only ones in "our" source and not in
qthreads proper
Add ability to remove a file or directory from Chapel code by
specifying its name, as well as tests of that functionality.
Clean up changes to rename: I misspelled occurred, and I decided to use
2> for the preexec error message instead of just repeating it.
Replace spinwait in syncvar unlock with qthread_yield

Testing out the correctness/performance implications of this. This makes sense
because if a qthread is just spinning while waiting on a sync var, we really
want them to yield, and let somebody else do some work.

I believe if we used real qthread sync vars we wouldn't need to do this, but
the yield in the unlock would still be needed.

It might also make sense to only do this every x iterations of the loop, but
that means adding a counter to that, which might not be worth it.
Merge pull request #189 from ronawho/qthreads-syncvar-deadlock

Replace spinwait in syncvar unlock with qthread_yield

[idea ok'd / from @gbtitus]

Testing out the performance implications of this. This makes sense
because if a qthread is just spinning while waiting on a sync var, we really
want them to yield, and let somebody else do some work.

I believe if we used real qthread sync vars we wouldn't need to do this, but
the yield in the unlock would still be needed.

It might also make sense to only do this every x iterations of the loop, but
that means adding a counter to that, which might not be worth it. We'll see
Update localeModels/gbt/maxTaskPar to handle ugni+flat+muxed.
Merge pull request #190 from gbtitus/maxTaskPar-for-Cray

Update localeModels/gbt/maxTaskPar to handle ugni+flat+muxed.

[Not reviewed.]
Merge pull request #192 from lydia-duncan/fileRemove

Add ability to remove a file/directory [reviewed by hilde]

Add ability to remove a file or directory using Chapel code. This follows the same
strategy as the C remove function - it will complain if the file to be deleted does not
exist, or if the directory to be deleted is not empty.

Details:
modules/standard/IO.chpl: Adds two functions removeFile, one which throws an
ioerror if one occurred and one which merely returns the error via an out
argument to the function. Both take in the name of the file or directory to be
removed. While I was there, I checked my spelling.
runtime/include/qio/qio.h
runtime/src/qio/qio.c: Adds backend support for the removeFile function in the form
of qio_file_remove. This function calls the C function remove on the given
filename and returns a qioerr translation of any error that may have occurred.
Another comment spellcheck.
test/io/lydia/remove: Adds four tests of the functionality - removing a file and an
empty directory work as expected, removing a file that doesn't exist generates
an error, and removing a non-empty directory generates an error.
test/io/lydia/rename: Altered my preexec so that it sends errors to the .exec.out.tmp
file instead of detecting if one occurred and sending a generic error.
Adding annotation for performance hit on array vs. ddata comparison
Merge pull request #193 from lydia-duncan/annotate

Adding annotation for performance hit on array vs. ddata comparison [trivial]

Occurred on 05/31/14.
Merge pull request #188 from ronawho/fix-chapel-qthreads-warnings

Fixes some bugs with print formatters that clang reports, but gcc doesn't

[reviewed by @gbtitus]

Just changes some print formatters.

Note that clang gives us a bunch of warnings about qthreads code that I shared
with the qthreads team. These were the only ones in "our" source and not in
qthreads proper
Fix some typos and when we print override message

Now only prints override message we actually overrode, rather than just if we
were able to set something.
Make eitherSet a chpl_bool
Merge pull request #187 from ronawho/qthreads-setenv

Add a helper function to set a qthreads env var

[reviewed by @gbtitus]

This is meant to mirror setenv functionality, but qthreads has two environment
variables for every setting: a QT_ and a QTHREAD_ version. We often forget to
think about both so this wraps the overriding logic. In verbose mode it prints
out if we overrode values, or if we were prevented from setting values because
they existed (and override was 0.)

Note that unlike setenv it is a void function and doesn't check if the value
to set contains an "=" or if the value is NULL, however I can update it if that
seems useful. We previously just ignored any errors anyways and since this is
internal use only, it seems fine.

This also puts a note at STACK_SIZE so we don't forget that we want to update
it's behavior.

I have some upcoming changes that will change qthread env vars and this is
something I always forget about when setting a qthread env var and I think it
makes setting a qthread env var cleaner, even though the function is kind of
large for what it does.