BLT subproject changes behavior of non-BLT parent project

Nobody has claimed this yet.

I have a large pre-existing CMake-based code base. We added a subproject to our code that uses BLT (pulled in as a subdirectory using git submodules), and many things in the parent project broke because BLT changes some global CMake variables. Specifically, `SetupBLT.cmake` sets `LIBRARY_OUTPUT_PATH`, `CMAKE_RUNTIME_OUTPUT_DIRECTORY`, and `CMAKE_Fortran_MODULE_DIRECTORY`, which changes the default behavior of many cmake routines for the entire project.

As a workaround, we had to go to every cmake routine affected by these global variables and explicitly set local variables to restore the old behavior.

I would expect and prefer that adding a CMake subproject that uses BLT to a CMake main project that does not use BLT would not result in any changes to the CMake behavior of the main project. This would be accomplished by having SetupBLT.cmake not change `LIBRARY_OUTPUT_PATH`, `CMAKE_RUNTIME_OUTPUT_DIRECTORY`, and `CMAKE_Fortran_MODULE_DIRECTORY`, and instead change the BLT macros to set local variables to replicate the desired behavior.

Start by reading SetupBLT.cmake and tracing where it sets LIBRARY_OUTPUT_PATH, CMAKE_RUNTIME_OUTPUT_DIRECTORY, and CMAKE_Fortran_MODULE_DIRECTORY. Review the BLT macros affected by those variables, then verify that embedding BLT leaves the parent project's defaults unchanged while preserving BLT's intended output behavior.

Written by the indexing model from the issue text.