Refactor: Improve performance of checklist listings.

This MR significantly improves the performance of checklist listings and simplifies the database schema for runs.

Supporting information

• Jira ticket: https://tasks.opencraft.com/browse/STAR-2809
• GitLab issue: #60 (closed)

Testing instructions

1. Start with the master branch
2. Create a team and assign yourself to it.
3. Create a checklist definition with 10 questions
4. Create 9 other users and assign them to the team
5. Create a recurrence that runs every 2 seconds and let it create a few pages of recurrences
6. Deactivate the recurrence for sanity
7. In the browser's network tab, observe the speed of the call to display the listing of users by visiting the front page and tabbing between the listings
8. Rename one of the checklists in the admin and complete it.
9. Tab back and forth several times in rapid succession. You should eventually be able to get the wrong list showing.
10. Switch to this branch and run migrations
11. In the browser's network tab, observe the speed. It should be several times faster.
12. Switching between the tabs shouldn't create additional fetches unless the search parameters have changed, and there should never be confusion between the tabs and the lists.

Author notes and concerns

There are many more potential performance gains that could be had here, but they are probably not worth tackling right now. In particular:

• The render time for lists appears to be pretty sluggish, and takes up a lot of the total time. The markup could probably be simplified, or else some other means of caching the list display could be helpful.
• Major changes to the serializers could also potentially increase the speed by avoiding the direct call of related objects. However this would make the API itself potentially less logically laid out, focusing too much on the current UI.
• It might be helpful to cache certain data on the run so that large joins aren't required-- such as keeping a field on the run that holds the total tallies, and is updated upon model saves, and associating users with runs directly. This would mean some data is a bit redundant and denormalized, but could be leveraged if performance is needed.