Add plugin architecture for extensible DICOMweb backends

[luckfamousa]

Summary

This PR introduces a plugin system that allows external implementations of DICOMweb services (QIDO-RS, WADO-RS, STOW-RS) via dynamically loaded shared libraries.

Key Changes

• New dicom-rst-plugin-api crate: Defines FFI-safe plugin traits using abi_stable for C ABI compatibility across Rust compiler versions
• Plugin loading infrastructure: PluginRegistry in src/backend/plugin/ manages loading and AET bindings
• Service adapters: Bridge FFI types to internal service traits (PluginQidoAdapter, PluginWadoAdapter, PluginStowAdapter)
• Configuration support: Plugins configured in config.yaml with path, AETs, and custom settings
• Example plugin: Demonstrates implementing all three plugin traits
• Documentation: CLAUDE.md updated with plugin development guide

Plugin Traits

Trait	Service	Methods
QidoPlugin	QIDO-RS	search(), health_check()
WadoPlugin	WADO-RS	retrieve(), render(), metadata(), health_check()
StowPlugin	STOW-RS	store(), health_check()

Configuration Example

plugins:
  - path: "/path/to/libcustom_plugin.so"
    aets:
      - CUSTOM_PACS
    settings:
      database_url: "postgres://localhost/dicom"

Feature Flag

The plugin system is behind the plugins feature flag:

cargo build --features plugins

Test plan

• Build with cargo build --features plugins
• Build example plugin with cargo build -p dicom-rst-example-plugin --release
• Verify plugin loading at startup
• Test AET routing to plugin vs built-in backends

🤖 Generated with Claude Code

[github-advanced-security]

clippy found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.