Store multiple crawls in a single database

[chosak]

This PR significantly alters the way this package uses a database. Instead of storing individual website crawls into separate SQLite database files, all crawls are now stored into the same Django database. This database can be configured to use any database backend supported by Django. Database tables are now managed by Django migrations, and a new Crawl model keeps track of the status of past crawls, including whether they succeeded or failed.

This PR also adds Python tests for 100% of testable Python code (excluding only the plugin to the wpull crawler, which is difficult to test without running a real crawl). This package has been migrated to pytest and pytest-cov for simpler testing and coverage checks. Moving forward, PR checks will fail if Python coverage drops below 100%.

(As a TODO, a future PR will need to add a management command to clean up old crawls, to ensure the database doesn't continue to grow indefinitely).

[chosak]

@willbarton in 5bf3d93 I added a workaround to handle missing SVG icons in the Python tests, when we haven't run the frontend build. Like cf.gov, the frontend build copies the CFPB Design System SVG icons from node_modules to where Django can see and load them inline during template rendering. We don't want to have to run the frontend install and build steps in order to successfully run the Python tests.

To get around this, I've added a simple template loader that ignores missing SVGs. Cf.gov has a bunch of custom code that handles this a different way (by inserting a placeholder SVG) which I'd prefer not to copy here. Thanks to @anselmbradford for counsel on different options.

Currently this project only has a single settings file that doesn't disambiguate between testing or dev or production. As part of future work I'll split that out so that this new loader isn't running in production, but this seems a reasonable path forward for now.