Automate release

[wpbonelli]

Release automation

Adds a workflow release.yml to make FloPy releases. There are some manual steps that must be completed before initiating the automatic release, as before (steps 1-5 in docs/make_release.md).

Approach

The approach is similar to that introduced in modflow6 PR 1069: the release.yml workflow is triggered by pushing a release branch named e.g. v3.3.6rc or v3.3.6. If the branch name ends with rc, it's a dry run and the workflow ends after updating version files, recreating plugin classes, updating the changelog, and running tests and notebooks. If the branch name doesn't end with rc the release is considered approved and production-ready, and after the preceding steps a draft PR is created from the candidate branch into master. Merging this PR triggers a job to draft a release. The release post's content is the changelog since the last release. Publishing the release triggers a final job to publish the Python package to PyPI. Opening a PR to update conda-forge/flopy-feedstock was considered but does not seem necessary as there seems to be a bot which auto-detects package updates and creates PRs for us.

Refactoring

A version.txt file is added in the project root. Functionality from scripts/make-release.py and scripts/update-version_changes.py is consolidated in scripts/update_version.py, which acquires a file lock and updates version numbers and timestamps, first in version.txt then in other files including flopy/version.py, README.md, etc. Sample usage:

python scripts/update_version.py -v 3.3.6 --approve

Changelogs are generated with git-cliff via orhun/git-cliff-action in the release workflow, and changes for each new release are automatically prepended to docs/version_changes.md, so code in scripts/update-version_changes.py is removed. A cliff.toml config file is added in the project root. The format of docs/version_changes.md is standardized. The updated procedure is described in docs/make_release.md.

get-modflow

• Fix extension handling issues I introduced in fix(get-modflow): fix code.json handling #1641
• Restore previous --subset matching behavior to include *dbl variants
• Split get-modflow script test cases by valid/invalid options for finer-grained debugging
• Ignore code.json for modflow6 and modflow6-nightly-build repos since they use a different format than executables

The first two items are a result of my jumping the gun in #1641 and "fixing" a test that was only failing due to temporary state of the executables repo releases.

Miscellanous

• sort etc/environment.yml
• lint autotest files and notebook utilities
• add pytest-dotenv as a testing dependency (allows defining environment variables e.g. GITHUB_TOKEN in a .env file)

[codecov]

Codecov Report

Merging #1642 (62c8a2d) into develop (3131e97) will increase coverage by 0.0%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##           develop   #1642   +/-   ##
=======================================
  Coverage     72.8%   72.8%           
=======================================
  Files          251     251           
  Lines        54517   54515    -2     
=======================================
+ Hits         39689   39719   +30     
+ Misses       14828   14796   -32     

Impacted Files	Coverage Δ
flopy/utils/get_modflow.py	63.9% <100.0%> (+6.5%)	⬆️
flopy/utils/parse_version.py	55.5% <0.0%> (-0.4%)	⬇️
flopy/utils/gridintersect.py	78.9% <0.0%> (+0.5%)	⬆️