Add file renaming functionality and tests.
Whitespace fix and move qio_file_rename so it wasn't interrupting the file_open
helper methods.
Merge pull request #185 from lydia-duncan/fileRename

Add file rename functionality and tests [reviewed by hilde]

Add the function renameFile to our IO module, as both an error generating
and an error returning function. This is supported by new qio runtime code
that makes use of the C function "rename".

Summary of changes:
modules/standard/IO.chpl - renameFile(err, oldname, newname) converts
oldname and newname to c_strings before sending them to qio_file_rename,
returning via err any error that may have occurred. renameFile(oldname,
newname) passes its arguments along to its sister function, and generates
an I/O error if one occurred.
runtime/include/qio/qio.h
runtime/src/qio/qio.c - adds qio_file_rename to qio. This method sends its
arguments to rename and returns the qioerr version of errno if an error
occurred.
test/io/lydia/rename/no_such_file - checks that the proper error is generated
if the file to move did not exist.
test/io/lydia/rename/rename_file - checks that files are actually moved.
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.