Adding logging to framework_test
Finish fixing bash_profile loading
Enable framework-specific install directories and environment

This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving #448

The new function replace_environ in setup_util.py goes a long way towards
addressing #899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile
Install web servers into docker containers

Introduces --docker flag
Use docker 1.13 api
Improve installation in docker containers

Lots of minor things:
- Mount the toolset directory so any toolset/* changes are included. Very useful for framework development
- Mount the test directory so any test/* changes are included. Very useful for test development
- Without the above mount changes, you will be rebuild the prerequisites container every time you want to
  change something
- Moved pertest installation directories inside of FWROOT/installs to avoid overwriting when mounting. This
  also seems a lot cleaner, just remove the installs directory to ensure everything is clean
- Delete installs/ directory before building prerequisites container to avoid including a ton of useless context
- Ensure autoremove is run in FWROOT instead of FWROOT/installs (which may not exist per above change)
- Add install-only flag to ensure installation step in docker containers doesn't try to run tests when installing
Run webservers inside docker container

Only tested *go* so far, but it does work as expected.

Setup uses an isolated container per test. Only webservers are inside
docker containers (database and client are both still running on separate hosts).
Passes SSH identity files and results between container and host system invisibly.
Provides live output of container's stdout and stderr to the user's terminal
So far, setup only has to use normal docker containers, not "heavyweight" containers
  that run system services such as syslog. We will see how many tests work inside a
  container as I start testing

Changes:
- Added docker-client flag. You can hackily figure out if you're running inside a container, but this is cleaner
- Modified run_tests to use custom function if --docker or --docker-client flags are used
- Added new run_test method, used when --docker flag is detected

TODO:
 - ensure support for all flags
 - avoid duplicating results parsing
 - testing testing testing
Adding Dockerfile
Always run tests, even if they were completed recently

This was added because some tests, like mono-based ones, tend to leave a
huge mess of open ports. Running these twice in succession caused them to
consistently fail the second time. This problem does not exist when the
tests are all inside containers, so I remove this limitation
Remove exception-hiding code

This try-except is not actually handling the exception, it is just
returning None which immediately results in an exception
TypeError. So the try-except does nothing but hide the real
OSError and confuse the user with a TypeError

Also, there is no need for the file.exists check inside
__parse_results as it is only called if the file exists
Add --time parameter to override default time calculation

Needed to ensure that tfb inside the docker container uses
the folder that we expect for results.

If we don't force the timestamp, then you end up with a results folder for
the tfb running inside docker and a results folder for the tfb running
outside docker, as their respective runtimes are different.

The folder created by tfb inside the docker container will have raw
results, while the one created outside the docker container will have only
the results.json file
Store docker image if installation or test run fails

Allows you to quickly peek inside a container in case of
failure
Ensure files/folders created inside docker container can be accessed outside

Because TFB runs as root inside the docker container, any folders or files
that are created inside the container can not be written to by the TFB
process running outside the docker container. Practically this means that
the parent TFB process cannot read write results.json inside the
<test>/<time> folder

The solution for now is to chmod 777 files when they are created inside the
container. The long term solution would be to create a user inside the container
that corresponds to a user outside the container and then run TFB as that
user inside the container.
Moved docker-specific logic out of run and into _run_docker
Minor improvements to output and logs

- Only main TFBs should print "results are in ... directory"
- Now prints "Running test container for ..."
- Adds support for a number of command-line flags
- Print container output a bit better w.r.t newlines
- Stop creating empty "raw" files (Oops!)
Better descriptions for command-line flags
Parse RAW results from container to load results[] in main process