Fix versioning in packages

Currently, packages are versioned in their own pyproject.toml. Versioning follows the CalVer schema, because that's what we use the 3DBAG data too. Each pyproject.toml contains bumpver configs such as below. This config create a tag for the whole monorepo, all packages, not just the package in question.

[tool.bumpver]
current_version = "2024.1004"
version_pattern = "YYYY.BUILD"
commit_message = "bump version {old_version} -> {new_version}"
commit = true
tag = true
push = false

[tool.bumpver.file_patterns]
"pyproject.toml" = [
    'version = "{version}"',
]

How do we sort out versioning so that we can have:

probably a single version for the whole repository
independent versions per package, so that we can pin them
that specific package versions are installable, because pip can install from git tag, branch, commit, but cannot look through the commits to find the commit where the pyproject.toml has the required version in it

The current idea is that we tag the master branch after each 3DBAG release, with the same version as the 3DBAG release. Thus the 3dbag-pipeline versions follow the 3DBAG versions exactly, indicating that eg. version 2024.11.15 3dbag-pipeline was used for producing version 2024.11.15 3DBAG.

The 3dbag-pipeline is hosted only here on GH (not on pypi). So if a software depends on the pipeline, I see two viable options for adding it as a dependency:

follow the releases and pin to the tag/release eg. bag3d-common @ git+https://github.com/3DBAG/3dbag-pipeline.git@v2024.11.15#egg=bag3d-common&subdirectory=packages/common
if you need a fix that was pushed to the develop branch after the latest release, pin to the commit of the fix eg. bag3d-common @ git+https://github.com/3DBAG/3dbag-pipeline.git@3aa36a0094fa4bacda4cbf0a77d57d1e6f8d7e09#egg=bag3d-common&subdirectory=packages/common

The 3dbag-pipeline packages are always installed from the git HEAD of the current branch, using relative package paths. For example core depends on common and it would always install it from the current local branch (not from a remote branch of GH). In case of a pinned version, the version (tag or commit) is checked out and that is the version of common/core/etc. that is installed.

This would ease our development process, because we wouldn't need to keep changing the git tag of common to point it to the current branch and back to develop when we are working on fix/PR. Also, we don't actually need to pin common in the workflow packages. Since common is deeply integrated with the rest of the packages, we usually end up changing it when we work on a package, so we always need the last commit.

However, unfortunately pip does not support relative paths, so we won't be able to use pip anymore. But uv seem to support it, although I haven't tried it. If we do it with uv, then #75 needs to be done . Poetry does support relative dependencies, but Poetry is so 2020...

3DBAG / 3dbag-pipeline

Fix versioning in packages #72