Update QC town close export script to prep for automation

[jeancochrane]

This PR makes a few quality-of-life improvements to the QC town close export script to enable automation via any distribution mechanism (VM, OneDrive, or S3). The changes include:

• Define a new Township class that owns a few different configurations for each township:
  • Township code and human-readable name
  • Tri code and human-readable name
  • Start/end dates for "active" periods, indicating periods when towns are eligible for QC
• Support for a config file at scripts/utils/town_active_schedule.csv that can optionally configure the list of available Townships
• Change the --township option so that it accepts one or more township codes
  • When the caller provides multiple codes, the script will output one workbook for each report and workbook readers can filter the township_code column for the township they are interested in
  • When the caller provides one code, the script will prepend the human-readable township name to the filename for each output workbook (e.g. "Res edit.xlsx" will become "Jefferson Res edit.xlsx"). This feature automates the renaming operation that we perform when exporting these reports manually
• Change the --township option so that it is optional, and when omitted, falls back to all towns that are active per the town_active_schedule
• Add an --output-dir option that controls the directory where the script will save reports

With these changes, we can follow these steps to define an automated process to export QC reports on a regular schedule:

• Create a scripts/utils/town_active_schedule.csv config file on the machine that will run the process (or download it from S3 in an ephemeral environment like a GitHub workflow) with a defined activity schedule
• Schedule a process to run the export_qc_town_close.py script at regular intervals
  • Omit the --township argument so that the script will export all active towns
  • Optionally set the --output-dir option on environments like the VM that need to write to specific locations but cannot chain an mv call to the scheduled export_qc_town_close.py call

[jeancochrane]

@dfsnow I finished a pretty major refactor of the PR, so I think it's worth taking a fresh look at everything. Instead of the no-filter default being a set of active towns determined by a schedule, the script will now default to exporting reports for all towns, using pandas to speed up the township filtering operation. Testing this locally, it takes about 30 minutes to run an export for all towns, and we scan the same amount of data in Athena since our tables are not partitioned by township anyway.