Fix NUMA build failure.

Application of FLAG_COMPILER_GENERATED caused locale.name to be selected in favor of
NumaDomain.name.  Assignment to this in the constructor then looked like an attempt to
write to an rvalue, so the Chapel compiler flagged it as an error.

I decided to back out the change.  It seems like in general a user wants the local field
name to bind at least as tightly as an inherited getter.  The compiler generates getter
and setter functions only if they are not provided by the user, so the "compiler
generated" flag is not really needed in this case.

I also backed out the change to classes/diten/nearestMutualParentClass, as the "compiler
generated" pragma is no longer needed there.
Migrate the codegen code from BlockStmt to the new Loop ASTs
Add a test case to show that getters in derived classes dominate.
Merge pull request #671 from hildeth/master

Fix NUMA build failure.

Application of FLAG_COMPILER_GENERATED caused locale.name to be selected in favor of
NumaDomain.name. Assignment to this in the constructor then looked like an attempt to
write to an rvalue, so the Chapel compiler flagged it as an error.

I decided to back out the change. It seems like in general a user wants the local field
name to bind at least as tightly as an inherited getter. The compiler generates getter
and setter functions only if they are not provided by the user, so the "compiler
generated" flag is not really needed in this case.

I also backed out the change to classes/diten/nearestMutualParentClass, as the "compiler
generated" pragma is no longer needed there.

This patch passes all but 6 multilocale tests with CHPL_LOCALE_MODEL=numa and CHPL_GASNET_SEGMENT=fast.  There are known comm-count differences in distributions/robust/arithmetic/performance/multilocale/
  reduceAlias
  reduceSlice
  reduce
There are also known sporadic timeouts in distributions/robust/arithmetic/
  modules/test_module_Sort
  slicing/test_array_slicing3
The remaining test 
  basics/test_zipper_default
now times out consistently on the test machine I was using (chap01).
Add some printfs to verify that the LLVM BlockStmt::codegen() isn't being used for Loops
Merge pull request #672 from noakesmichael/loopWrap-2

Move loop codegen from BlockStmt to new AST nodes

Compiled: STD clang on mac, STD gnu on linux, LLVM gnu on linux
Tested: Full paratest with STD --verify and LLVM --verify
Reviewed: None