config through env vars

This is a PR for #347

This adds a default `env.yml` file which supports all options through environment variables.
You can use this to launch a container and set any parameter without having to inject your own config file.

Example usage:

    docker run \
      -e SETTINGS_FLAVOR=s3 \
      -e AWS_REGION=us-west-1 \
      -e AWS_BUCKET=my-docker-bucket \
      -e AWS_KEY='AKIASDHAF48HSKDAF' \
      -e AWS_SECRET='SAGDKFJSHDKFJHAVUSKDJFSHKLDFLSDF' \
      -e SECRET_KEY='foo'  \
      -e SEARCH_BACKEND=sqlalchemy \
      registry

You can also launch without any settings to get the `dev` 'flavor' which will launch local storage with sqlalchemy enabled.
&nbsp;

I tried to get every single config parameter possible, but they are scattered around all over the place, so it is very likely I missed a few.

I also wasn't sure how to go on defaults. This bit should probably be determined and cleaned up. For example in the new `env.yml`, `s3_encrypt` defaults to `true` if not specified. I did this as this is the value set in `config_s3.yml`. But I'm not sure if we want to leave this unset and let the code handle it.
But then on some things like `config_path`, I think a default makes sense. So which parameters get defaults and which don't?

&nbsp;

The other thing is the env var names. I tried to preserve the existing variable names if they were documented or used already. However the names are rather inconsistent. For example, the s3 bucket var in `config_s3.yml` is `$AWS_BUCKET`, but in the `setup-configs.sh` it's `$S3_BUCKET`. Then `swift_container` is `$SWIFT_CONTAINER`, but the rest of the vars are `$OS_...`.

I personally think it would be best if all the vars for a storage engine were prefixed with that engine name. So `engine: swift` would be `$SWIFT_AUTH_URL`, not `$OS_AUTH_URL`.

&nbsp;

Lastly I have only tested the `s3`, `local`, and `dev` 'flavors'. I don't have the other services to be able to test them.