Improve Docker setup + make commands

[ddabble]

This depends on #767.

Proposed changes

• Improved Docker setup (34298b3)
  • Environment variables specific to Docker can now be provided using a .env.docker file
  • The image is now based on the latest stable Ubuntu release, like the prod server
  • Static and media files are persisted between runs (through a volume)
  • Added Docker-specific make commands, all prefixed with d-
  • Stopped always running migrations when starting the container; it's more useful having manual control, using e.g. make d-migrate
• Renamed and added some more make commands (0f5f1f2)

Also moved and renamed the Docker-related files (7141f4d).

Review guidance

Test it out locally and post any feedback here 🙂

Checklist

(If any of the points are not relevant, mark them as checked, so that it's easy to see which points you've handled or not)

• I've run makemigrations, makemessages and compilemessages
• I've written tests that fail without these changes (if relevant/possible)
• I've manually tested the website UI with different device layouts
  • Most common is to test with typical screen sizes for mobile (320-425 px), tablet (768 px) and desktop (1024+ px), which can easily be done with your browser's dev tools
• I've manually tested with different users locally
  • This can be e.g. anonymous users (i.e. not being logged in), "normal" non-member users, members of different committees, and superusers
• I've made sure that my code conforms to the code style guides
  • It's not intended that you read through this whole document, but that you get yourself an overview over its contents, and that you use it as a reference guide / checklist while taking a second look at your code before opening a pull request
• I've attempted to minimize the number of common code smells
  • See the comment for the previous checkbox
• I've added documentation
  • E.g. comments, docstrings, or in the README
• I've added my changes to the "Unreleased" section of the changelog, together with a link to this PR
  • Mainly the changes that are of particular interest to users and/or developers, if any
• I've added a "Deployment notes" section above and labelled the PR with has-deployment-notes
  • ...if anything out of the ordinary should be done when deploying these changes to the server (e.g. adding/removing an environment variable, manually creating/changing some objects, running a management command, etc.)
• I've structured my commits reasonably
  • Some tips on this can be found in "Write Better Commits, Build Better Projects" and in the code style guides
  • Restructuring commits after they've already been committed, can be done using e.g. interactive rebase; see the Git docs on rewriting history

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 88.04%. Comparing base (674c6f6) to head (34298b3).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
src/web/management/commands/runserver.py	0.00%	1 Missing ⚠️

❌ Your patch status has failed because the patch coverage (0.00%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #768   +/-   ##
=======================================
  Coverage   88.04%   88.04%           
=======================================
  Files         153      153           
  Lines        6224     6224           
=======================================
  Hits         5480     5480           
  Misses        744      744           

Files with missing lines	Coverage Δ
src/web/management/commands/runserver.py	0.00% <0.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[TheStrgamer]

It works as intended when i run it locally, and the documentation in the readme is easy to understand. I also like using custom make commands (especially since we are make), as it makes the commands smaller and easier to remember