Improve tooling for static files

A comment on another MR brought up the point that vendor files could be kept uncompressed for ease of development, then compressed when deployed to a server. This is a fairly common methodology for handling static front-end files in a website project like this, and there are several benefits to it - from having easier-to-reference sourcefiles to use when bugfixing, to keeping git commits from being needlessly weighed down by yet another *.min.css file declaring yet another full-text change.

At present, static files are managed via NPM scripting. Before this commit, the available NPM scripts for frontend code management worked well but inconsistently:

• SASS was compiled into compressed CSS, but JS was not compressed
• Third-party (or "vendor") JS was not affected by the NPM management scripts, and was instead placed by hand into the destination folder
• Vendor JS was compressed, in contrast to the project's custom JS

This MR addresses these inconsistencies in several ways:

• There are now separate build and prod script types for managing static files. build will move CSS and JS from /static/ to their web- accessible location inside /tordonate/ but will not compress them. prod will move and compress them.
• There are build and prod shortcut scripts which, when run, will execute the steps to copy (and, in prod's case, compress) JS and CSS to the proper web-accessible location, and do so one time.
• The start task works as it always has - by executing all build tasks once, then seeting up watchers to rerun build tasks when source files change - and, as it is intended for development purposes, continues to use those no-compression build tasks.

A few other changes were made in conjunction with these modifications to the NPM scripting:

• Certain filenames were renamed for consistency, and those changes were reflected in source where references to those filenames were made. (See tordonate/templates/scripts.html, for example.)
• README.md has been updated to denote the three main NPM script invocations and clarify the differences between them and their intents.

Note that this MR does not remove any static files from their web- accessible location, even though this makes for a redundant set of them. That is because the deployment process for this codebase does not itself currently compile static files. It is the intent of this MR to provide a straightforward way for this compilation to occur - and hopefully, npm run prod is straightforward enough - and to spark a discussion about how to work this into the deployment tooling. Once tooling is in place to compile static files into tordonate, another MR (or perhaps a subsequent commit to this one) will be made to remove this second, redundant set of static files.