Consider migrating to Poetry for dependency management and releases

[RaulSMS]

Proposal

Some other repos I maintain use Poetry as the dependency manager and to help with releasing pip packages. Worth evaluating whether the same makes sense here.

Context

Assessed as part of the issue #70 rework of the release workflow. See comment below for the recommendation.

[RaulSMS]

@VKlueber I'd recommend against migrating to Poetry, for this repo specifically:

• Trivial dependency surface. One runtime dependency (python-can>=4.2.0) plus two small dev extras (test, lint). Poetry's main value — lockfile-based resolution across a large/conflicting dependency graph — has nothing to resolve here.
• No packaging pain to solve. pyproject.toml already uses setuptools cleanly, with dynamic version sourced from j1939/version.py. There's no legacy setup.py/setup.cfg fragmentation that Poetry would be cleaning up.
• Would downgrade release security. publish.yml currently publishes to PyPI via trusted publishing (OIDC) through pypa/gh-action-pypi-publish, plus SLSA provenance generation. Moving to poetry publish means either re-plumbing OIDC trust for Poetry's publish flow (more complex, less standard) or reverting to token-based auth — a step backward on supply-chain security, not forward.
• Added CI overhead for no behavioral gain. CI currently does a plain pip install -e .[test] / .[lint]. Poetry would add an extra tool dependency and installation step to every job across 3 OSes x 4 Python versions, without changing what actually gets installed.

Poetry earns its keep when a project has a large/conflicting dependency tree or is fighting legacy setup.py-based packaging. This repo has neither problem.

Closing recommendation: keep the current setuptools + pyproject.toml + trusted-publishing setup as-is.