Add some PR template checkboxes

Proposed changes

Added a few things that should almost always be done before opening a PR, which are often easily forgotten - especially for newer members/contributors. With this, the checkbox list is starting to grow quite large, but I think it's still manageable, and that it strikes a decent balance between brevity and completeness.

Also split the checkbox linking to CONTRIBUTING.md in two, which should make it clearer that both the code style guide and common code smells should be followed/addressed.

Areas to review closely

Checklist

(If any of the points are not relevant, mark them as checked)

[x] Remembered to run the makemigrations, makemessages and compilemessages management commands and committed any changes that should be included in this PR
[x] Created tests that fail without the changes, if relevant/possible
[x] Manually tested that the website UI works as intended 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)
[x] Manually tested that everything works as intended when logged in as 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)
[x] Made sure that your 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)
[x] Attempted to minimize the number of common code smells
- (See the comment for the previous checkbox)
[x] Added sufficient documentation - e.g. as comments, docstrings or in the README, if suitable
[x] Added your changes to the "Unreleased" section of the changelog - mainly the changes that are of particular interest to users and/or developers, if any
[x] Added a "Deployment notes" section above, if anything out of the ordinary should be done when deploying these changes to the server
[x] Structured your 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)

MAKENTNU / web