Use uv for managing dependencies

[osma]

This PR switches to uv for dependency management instead of Poetry.

Included changes:

• migrate pyproject.toml to work with uv; for example, declare the dev dependencies using standard [dependency-groups] section
• update README.md to explain how to use uv commands for development installs
• migrate GitHub Actions to use uv instead of Poetry
• migrate Dockerfile to use uv instead of Poetry
• configure flake8 to skip e.g. .venv directory (uv will create the virtual environment there by default)

Some notes:

1. uv doesn't have a command for permanently activating the venv like the old poetry shell or the newer equivalent eval $(poetry env activate). It is recommended to use uv run every time, but I think that's cumbersome. However, the venv can simply be activated using source .venv/bin/activate so I recommended that in the README. (There is an open issue about this, but it seems that implementing this properly to handle all edge cases is a bit difficult, so the developers hesitate to do it.)
2. I changed the Docker base image to one provided by Astral / uv: ghcr.io/astral-sh/uv:python3.12-bookworm-slim. An alternative would have been to keep the vanilla base image python:3.12-slim-bookworm and just install uv within that.
3. I think that the GitHub Actions action astral-sh/setup-uv is handling all caching of dependencies, but I haven't verified that it works in a sane way...

Overall, uv seems a bit faster than Poetry. For example, the GitHub Actions run completes in less than 3 minutes, when it used to take a bit more than 3 minutes (though with a lot of variation).

In the future, using uv should enable better management of PyTorch variants when we add it as a dependency (for example for the EBM backend - see #914 ).

Closes #919

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.63%. Comparing base (2f7ff89) to head (aa502b7).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #923   +/-   ##
=======================================
  Coverage   99.63%   99.63%           
=======================================
  Files         103      103           
  Lines        8238     8238           
=======================================
  Hits         8208     8208           
  Misses         30       30           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[osma]

There's a potential problem when using uv together with custom spaCy models. python -m spacy download downloads a model and installs it as a Python package into the current venv using pip (that's why I added pip as a dependency in this PR; see also explosion/spaCy#13846). But the new model package is not registered in pyproject.toml, so uv doesn't know about it. Next time you run uv sync for any reason, it will delete this "extra" package, unless you give it the --inexact flag every time (there is no permanent setting for this).

This has been reported as astral-sh/uv#12481 but it was closed by uv developers as they are not planning to support this kind of use.

This has also been discussed in explosion/spaCy#13747 where it was suggested to call e.g. uv run spacy info en_core_web_sm --url to get the package URL and then passing it to uv add to add a real dependency tracked by uv. But we want to be flexible and allow users to install any spaCy models they need, so having to modify pyproject.toml (via uv add) seems a bit wrong.

OTOH, this only affects development installs (and currently Docker images that also use uv). A regular user installing Annif via pip install annif[spacy] would not be affected by this unless they specifically use uv pip.

[osma]

Note to self: The pip dependency could be moved to the spacy extra instead of having it as a top level dependency. Nothing but spaCy depends on it.