Use heroku container registry to deploy the webapp

[hdoupe]

This PR follows the advice given in the heroku/conda-buildpack repo which recommends that apps should deploy from the container registry instead of a buildpack. To complete this PR, I need to:

• Establish where the staticfiles should be stored (in the app or in an S3 bucket)
• Initially this will be deployed as a separate heroku app. Once it has been tested thoroughly, it should be given the ospc.org domain name [EDIT: See comment]
• Set up the services from the previous applications such as monitoring and logging
• Review the environment variables to see what is still used, what needs to be updated, etc.

This PR follows up on the initial work in converting PolicyBrain to Python 3 in #886.

[hdoupe]

It looks like most projects store staticfiles within the project directory. I plan to continue to do this unless we run into issues with this down the road.

[hdoupe]

This version of the app is up at https://ospc-docker-test.herokuapp.com/ if anyone is interested in testing it out.

[hdoupe]

This version of the app is up at https://ospc-docker-test.herokuapp.com/ if anyone is interested in testing it out.

I moved the app to https://ospc-test.herokuapp.com/ to make sure it was primarily under the main OSPC heroku account.

[hdoupe]

Status update: As soon as I get this working, a new PB version will be released. I'm having some issues with the staticfiles that only came up when I merged in changes from last week. Hopefully, I can get this taken care of and a release out soon.

[hdoupe]

PR #889 is ready to go.

• PolicyBrain is now deployed with Docker via the Heroku Container Registry

• Static files are now served via whitenoise. This resolved an issue where the static files were not found at their expected path. In the process of resolving this, I learned that Django does not claim to have a "production" ready static file server. Its static file server is meant for development:
  
  (source: https://docs.djangoproject.com/en/2.0/howto/static-files/)
  White noise was chosen primarily for its ease of setting up but also for its performance. There are ways to configure it further to hook it up to a higher performance CDN type setup if needed. Early on in the project, the files were served from a S3 bucket, but this bucket hasn't been updated since 2016 and does not appear to be used anymore.

• A few paths for static file locations were misconfigured. These were fixed in this PR, too.

Next up:

• Hook up a copy of the production database to the test server running this code. This allows for testing retrieval of previous runs. This also gives me an opportunity to practice moving a postgres server from one heroku app to another before doing it for the production site.
• Once this has been thoroughly tested, this site will become the new test site, a copy of it will be created to be the new production site, the production database will be migrated to the new production site, and finally, the domain name will be transferred to the new production site.