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.
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.]