Separate test installation directories and environments

This PR introduces the potential to install items into per-test directories using the new flag `--install-strategy (unified | pertest)`. Adding this necessitated a consistent way to reference the environment, so this PR also creates an environment variable `FWROOT` that is propagated to all subprocesses/subshells (a number of setup.py files already create a similar variable, this just formalizes it into the framework). A similar variable `IROOT` tells each subshell or subprocess where its `installs` directory is. 

Propagating these core variables fwroot/iroot allows each test to declare it's own environment relative to these variables. For now, I've placed environment declaring code in `<test-dir>/bash_profile.sh`, but there's likely a better name. See [go/bash_profile.sh](https://github.com/hamiltont/FrameworkBenchmarks/blob/f5a6539d3cc1e8ed63401996522e1ad3922be79c/go/bash_profile.sh) for an example of the `go` test declaring it's own environment using these variables. 

This is entirely backwards compatible - unless a test overrides the default environment with it's own `bash_profile.sh`, the default environment is what is used. This also removes the need to copy over top of `~/.profile, ~/.bash_profile, ~/.bashrc`, as this loads the default environment itself and don't rely on bash to load it automatically. 

This is all based on #900, which can be a bit confusing. To see a clean comparison of what this adds, please visit [this comparison](https://github.com/hamiltont/FrameworkBenchmarks/compare/3ebf5530cc17ed2b6117970ba9758a77e3e713b5...environ). I based it on #900 because it was a lot easier

This PR resulted from discussion on #899. It should also help to close #448 if merged

This is not fully tested, just putting it out for comment before I spend time testing. I've run enough tests to know it works generally, but it likely needs some cleanup. Also, I've dropped the `--install-software` flag because it was redundant with `--install`

`x in d` is more Pythonic than `x in d.keys()`.