Split core dependencies from models extra

[clemsgrs]

Summary

This change separates slide2vec's lightweight core dependencies from the heavier model integration stack and introduces a dedicated slide2vec[models] extra for the full model runtime.

Users who only need the core package surface, artifact handling, and configuration helpers can continue to install the base package without pulling in the full model stack. Users who want model execution can opt into the models extra or the repository's foundation requirements overlay.

Problem

The repository's dependency story mixed together core runtime requirements and optional model-integration requirements. That made it hard to isolate the minimal install surface, and it also blurred which dependencies were truly required by core modules versus only needed for model backends and external integrations.

While splitting the dependencies, there was an important constraint to preserve: several packages that look model-adjacent are still imported by core data and inference paths. In practice, torch, torchvision, einops, wholeslidedata, matplotlib, and wandb still need to remain in the base/core requirements because those modules import them directly.

Root Cause

The original packaging metadata and repository requirements files treated all runtime dependencies as one layer. The repository also had a runtime transformers type import in slide2vec.data.dataset, which made the split more coupled than necessary.

Fix

This PR updates setup.cfg so the package metadata keeps true core runtime dependencies in install_requires and moves the heavier model integration packages into a models extra.

It also updates requirements.in and requirements.txt so the shared core runtime dependencies stay generic there, while requirements-foundation.in layers on top with the stricter torch, torchvision, and einops version constraints used by the full model runtime. The Docker build paths were updated to install from that full overlay.

To make the boundary cleaner, slide2vec.data.dataset now keeps the transformers import under TYPE_CHECKING and uses a lightweight runtime capability check instead of a runtime BaseImageProcessor type import.

Finally, the README and dependency regression coverage were updated so the public install story and the packaging rules stay aligned.