use dynamic versioning

[sneakers-the-rat]

instead of handcoding the version, let's just use the git tags. this is en route to continuous deployment where we just cut a new version by pushing a new tag. it will also let us give unambiguous version information for provenance sake when we start embedding version in configs and output data

• v0.0.0: when you are on a clean checkout (nothing changed, nothing staged) of a commit with a tag with the pattern v.*, that is the version. i.e. when a CI/CD action is triggered by a new tag starting with v, that will be the version. We don't use tags for anything else atm so there shouldn't be a problem of accidentally making a non-version tag that starts with v, but in any case we'll deal with that in the cd action.
• v0.0.0.dev{n}+{hash} (e.g. 0.4.2.dev8+g56b32b7) where n is the number of commits after the last version tag and hash is the short hash: when you are on a clean checkout (nothing changed, nothing stages) of a commit without a version tag. The n is computed relative to the closest tag in the commit history
• v0.0.0.dev{n}+{hash}.d{time:%Y%m%d} (e.g. 0.4.2.dev8+g56b32b7.d20241106): when you are on a dirty commit with no version - aka you have uncommitted or unstaged changes in the repo.

also added __version__ const as is outdated but still treasured tradition

see: https://backend.pdm-project.org/metadata/#dynamic-project-version

---

📚 Documentation preview 📚: https://miniscope-io--56.org.readthedocs.build/en/56/

[coveralls]

coverage: 77.22% (+0.05%) from 77.17%
when pulling b56c893 on dynamic-versioning
into f6b05cd on main.

[sneakers-the-rat]

@t-sasatani this look ok? i think it'll help out with your experiments where you can log the fine-grained version along with your runs in case you end up hacking on miniscope-io while you're running and don't want to have to worry about keeping track of that.

in the future it will make it easier to deploy, where we just need to push a tagged commit to build the package and make a release. i'm gonna work on some other stuff later for autobuilding the changelog from messages in the PR, but i'm gonna hold off on that until i get the pipelining stuff drafted bc that's not a great use of time lol

[t-sasatani]

Looks good to me, and no way this can break mio functions anyway!