Don't commit poetry.lock

[dimbleby]

As python-poetry/poetry#7488 notes, poetry's own documentation recommends not committing lockfiles for libraries.

This project should practice what it preaches.

(It could be reasonable to reject this MR on the grounds that it's in some way more complicated than that - but then the docs should acknowledge that complication)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[radoering]

I'm a slight -1 for this and +1 for changing the docs because with a lock file you always know which dependencies work for sure. Without a lock file, you will get more failures unrelated to your changes. Then, you'll have to realize the failure has nothing to do with your change, search for a successful CI run, check if some dependency changed, ...

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[github-advanced-security]

You have successfully added a new SonarCloud configuration ``. As part of the setup process, we have scanned this repository and found no existing alerts. In the future, you will see all code scanning alerts on the repository Security tab.

[ralbertazzi]

Now that python-poetry/poetry#7506 has been merged I think the documentation is aligned with us keeping the lock file. I would close this PR, and - why not - have a round of dependencies update as the documentation suggests :)

[radoering]

I'll close this for now since no maintainer has expressed agreement so far and the documentation no longer recommends not to commit the lockfile.