Add configurable ONNX provider selection

[hanclintoclaw-pixel]

Summary

Closes #22.

This adds a small provider option to both neural runtime classes:

• provider="auto" is the default and prefers installed accelerator providers before CPU
• provider="cpu" forces CPU for predictable behavior
• provider="gpu" requires an accelerated ONNX Runtime provider and raises a clear error if none are available

The implementation keeps the public API intentionally small (auto / cpu / gpu) and hides ONNX Runtime provider names behind an internal resolver. That matches CollectorVision's simple quickstart-oriented API while still making GPU acceleration possible for users with the right runtime installed.

CollectorVision no longer declares ONNX Runtime as a dependency. Users install exactly one ONNX Runtime backend appropriate for their machine (onnxruntime, onnxruntime-gpu, DirectML/ROCm variants, etc.), and CollectorVision gives an actionable error the first time neural inference is used without a backend installed. It also warns if both onnxruntime and onnxruntime-gpu distributions are present because they provide the same Python module and can conflict.

Rationale

Before this change, NeuralCornerDetector and NeuralEmbedder both hardcoded providers=["CPUExecutionProvider"], so installing onnxruntime-gpu was not enough to use GPU acceleration through CollectorVision. The new default behavior is accelerator-first because that is what most users expect when a capable provider is installed, but it still falls back to CPU if automatic accelerator session creation fails.

Explicit gpu does not fall back silently because a user forcing acceleration should get a visible setup error if no accelerator provider is available or the runtime/drivers are not correct. ONNX Runtime can still use CPU as a graph fallback behind an accelerator provider when only part of a model is supported.

I did not add broad ONNX Runtime provider-list plumbing to the main API because it would expose too many magic strings for a library that is intended to stay easy to use. gpu is the meaningful user-facing choice across CoreML, CUDA, DirectML, ROCm, and future accelerator providers; we can add advanced provider-list support later if a concrete use case needs it.

Testing on train4070 exposed two packaging/runtime issues that shaped this final approach:

• Extras cannot cleanly replace a base onnxruntime dependency, so GPU installs can accidentally install both onnxruntime and onnxruntime-gpu, causing the CPU wheel to win and hide CUDA.
• Latest onnxruntime-gpu 1.27 requires CUDA 13 runtime libraries on train4070, while 1.26 plus CUDA/cuDNN Python runtime packages works on CUDA 12. CollectorVision should not globally pin that decision because newer CUDA users should be able to use newer ONNX Runtime builds.

Validation

• uv run --with pytest python -m pytest tests/test_onnx_providers.py tests/test_interfaces.py
• uv run --with ruff ruff check collector_vision/onnx_providers.py collector_vision/detectors/neural.py collector_vision/embedders/neural.py tests/test_onnx_providers.py
• Smoke-tested NeuralEmbedder and NeuralCornerDetector with provider="cpu", provider="gpu" on CoreML, and default provider="auto"
• Fresh install with no ONNX Runtime backend imports collector_vision successfully and raises actionable backend-install guidance when NeuralEmbedder() is constructed
• Warns once per process when both onnxruntime and onnxruntime-gpu distributions are installed
• On train4070 Linux/CUDA/RTX 4070, fresh pip install -e . followed by manual pip install "onnxruntime-gpu<1.27" nvidia-cudnn-cu12 nvidia-cuda-runtime-cu12 exposed CUDAExecutionProvider, passed targeted tests, and ran real detector + embedder inference with active providers ["CUDAExecutionProvider", "CPUExecutionProvider"]