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.