Simplify and modernize DeepLabCut Docker images and build pipeline #3282

Summary
Rework the docker/ images and build flow so public tags match real use cases, reduce overlap between base and core, align installs with released versions, and replace the build.sh matrix with a maintainable, CI-friendly approach.

Problem

• base vs core differ only by an unused env variable DLClight and a MOTD; end-user tooling (deeplabcut_docker.sh) only uses core and jupyter, so publishing and documenting base separately adds little value.
• Version skew: base installs DLC from Git, but not tagged DLC versions.
• Build script: build.sh needs updating. It builds via echoed args and xargs, copying examples/ into docker/ though Dockerfiles do not need it for the image build; helper greps may not match image names.
• CUDA × stage matrix misses clear policy for which variants must stay supported.

Proposed direction

• Images: prefer a single primary runtime image. Drop base, and optionally keep jupyter if it is still used.
• Dockerfile layout: One multi-stage Dockerfile explicit targets instead of four parallel Dockerfiles and bash script
• Install source: Install deeplabcut==${DEEPLABCUT_VERSION} from PyPI (or GH release) so tags match shipped code

Acceptance criteria (suggested)

• Public Hub tags and README describe at most runtime + jupyter (plus test if still published), with base removed from public docs.
• Image DLC version matches the tag (no silent “always main”).
• Developers can still build/push via one documented command, but replacing the bash script with modernized approach (e.g. single multi-stage Dockerfile).