Don't include developer-specific settings files in the repo

[StephenChan]

Putting developer-specific settings in the repo (dev_beijbom.py and dev_stephen.py in our case) potentially serves as a useful example for someone else to set their own settings. It also serves as a backup in case we lose our respective settings. However:

• This scheme adds friction to the process of potentially expanding the CoralNet dev team. A new dev, even when just trying things out, would either need to:
  • Create their own dev_<name>.py file and add it to the repo
  • Create their own dev_<name>.py file and remember to not commit it
  • Use one of the existing dev-specific settings files verbatim
• We could just as well include a sample settings file in the repo, with explanatory comments, to help prospective devs get started (including us if we lose our personal settings files).

We originally got this scheme of developer-specific settings files from Two Scoops of Django 1.8. (Not to point fingers at them, as that was written back in 2015.)

I propose using something like django-environ instead. With this, our dev-specific settings would be allowed to live either in a .env file (which should be git-ignored), or in system environment variables. This scheme could actually replace both dev_<name>.py and secrets.json, thus consolidating our settings a little bit. The env-vars option could be more convenient for production, continuous integration, etc.

One advantage of the .env / env vars scheme is that it's a familiar scheme across different programming frameworks, not just Django - you may see django-environ refer to the term 'Twelve-factor methodology'. The aforementioned sample settings file could be named anything we want, but I've seen it named as .env.dist in other projects, so we can use something like that.